Okay,
You think will be supported on next release?
Lamine
↧
Reply To: JRebel remote ; do not sync pom.xml dependency changes
↧
Reply To: JRebel remote ; do not sync pom.xml dependency changes
There are complex technical limitation, so for now it’s not on a board.
Kind regards,
Valerie
↧
↧
Reply To: JRebel remote ; do not sync pom.xml dependency changes
Okay no problem, I will organise myself to limit that issue in future
↧
Reply To: JRebel remote ; do not sync pom.xml dependency changes
Thank you
↧
JRebel Android – How to disable JNI linking
I bought the single version of JRebel Android and I can’t get it run. I got the message:
#############################################################
JRebel for Android 1.1.8 (2016-04-05T15:22:46+0000)
(c) Copyright ZeroTurnaround AS, Estonia, Tartu.
#############################################################
Logs are kept in: /Users/jeremie/.jrebel-android/logs/com.plante.android.cobalt/debug
Preparing application… This may take a minute.
JRebel for Android terminated: JNI linking detected.
JNI linking is not available with JRebel for Android individual license.
Process finished with exit code 1
I’ve been trying to disable the JNI link for about 2 hours and i’m always getting the same error. Can I know how to do so to get it working?
Currently I tried few solution including adding this line in the Gradle plugin file and removing JNI folder
sourceSets {
main {
jni.srcDirs = [] //disable automatic ndk-build
}
}
↧
↧
Reply To: JRebel Android – How to disable JNI linking
Hi Jeremiah,
the JNI usage probably comes from one of the libraries that you use.
Please use Tools > JRebel for Android > Send Feedback in Android Studio to send us logs so we can dig into this.
↧
Reply To: JRebel 6.4.2 breaks some Spring beans
We have now hotfix JRebel version 6.4.2a available, where the issue is resolved.
↧
Reply To: Can not autowire final classes with jrebel 6.4.2
We have fixed the issue and released hotfix JRebel version 6.4.2a.
↧
Reply To: Problem with springmodules-cache and 2.0-RC1 [SOLVED]
We have fixed the issue and released hot-fix JRebel version 6.4.2a.
You can download it form here: https://zeroturnaround.com/software/jrebel/download/#!/have-license
↧
↧
JRebel custom plugin for SiteMesh
My web application has a custom theme management system where a ThemeManager class reads in a jar file and then copies the contained files to various contexts such as the core application, CAS (authentication server) and a CMS. I am using Maven and I am finding that SiteMesh is reading in the decorators.xml file from src/main/webapp/WEB-INF rather than target/ROOT/WEB-INF. Having raised a previous support issue to get the ThemeManager class to copy the files to the target/ROOT directory I was given a code sample from which to create a custom plugin. That plugin worked perfectly and my theme files are now deployed to target/ROOT/xyz. However I noticed that the decorators.xml was never deleted from the src/main/webapp/WEB-INF and as it turns out SiteMesh was reading in that file rather than the one in the themes jar file. I created a new plugin based upon the code that was given to me as follows:
public class SiteMesh implements Plugin {
public static final String AFFECTED_PACKAGE = "com.opensymphony";
/**
* Set up the integration (register CBPs)
*/
@Override
public void preinit() {
IntegrationFactory.getInstance().addIntegrationProcessor(
getClass().getClassLoader(),
AFFECTED_PACKAGE,
new JavassistClassBytecodeProcessor() {
@Override
public void process(ClassPool cp, ClassLoader cl, CtClass ctClass) throws Exception {
cp.importPackage("org.zeroturnaround.javarebel");
ctClass.getDeclaredMethod("getRealPath").instrument(new ExprEditor() {
@Override
public void edit(MethodCall m) throws CannotCompileException {
if (m.getMethodName().equals("getRealPath")) {
m.replace("$_ = ServletIntegrationFactory.getInstance().getTransparentRealPath((RebelServletContext) $0, $1);");
}
}
});
}
});
}
}
However SiteMesh still reads in the file from the ‘src’ folder. Is it not possible to specify a package to be modified or must it be a class level decleration only such as com.opensymphony.sitemesh.factory.DefaultFactory?
↧
JRebel 6.4.2 in Eclipse Mars 4.5.2 in comb. with GF 3.1.2.2 no longer working
Yesterday I updated Eclipse with the new JRebel plugin and since that time my GlassFish won’t start any more:
WC1420: Error invoking ServletContainerInitializer org.apache.jasper.runtime.TldScanner
org.apache.jasper.JasperException: PWC6180: Unable to initialize TldScanner
If I disable JRebel for that server everything is fine.
Any help would be appreciated.
Regards Markus
↧
Reply To: JRebel 6.4.2 in Eclipse Mars 4.5.2 in comb. with GF 3.1.2.2 no longer working
Hello Markus!
As for now there is no known issues with the GlassFish integration, we need more information from you side. Could you please send your trace level jrebel.log file after reproducing the issue to support@zeroturnaround.com with the link to this forum topic? You can find the instructions on how to generate that file here: http://manuals.zeroturnaround.com/jrebel/misc/sendinglogs.html.
The full error stack trace would also be really helpful!
Kind regards,
Valerie
↧
Reply To: Reloading ATG properties files
Hi All,
I recently make ATG10.1.2 configuration changes and worked very good, here are the steps that I did.
http://obed33.blogspot.com/2016/04/jrebel-atg-oracle-commerce.html
This also works on ATG11.1 :)
Regards,
Obed
↧
↧
Reply To: JRebel custom plugin for SiteMesh
Hi!
You must list each class that needs patching by the given ClassBytecodeProcessor. Unfortunately package names can’t be used. There is an overloaded version of addIntegrationProcessor that accepts an array of class names.
It is possible to write a more generic JavassistClassBytecodeProcessor that can be used with multiple classes. To patch usages of ServletContext#getRealPath in all methods of a class:
public void process(ClassPool cp, ClassLoader classLoader, CtClass ctClass) throws Exception {
cp.importPackage("org.zeroturnaround.javarebel");
for (CtMethod ctMethod : ctClass.getDeclaredMethods()) {
if (ctMethod.isEmpty())
continue;
ctMethod.instrument(new ExprEditor() {
@Override
public void edit(MethodCall m) throws CannotCompileException {
if (m.getMethodName().equals("getRealPath") && m.getClassName().equals("javax.servlet.ServletContext")) {
m.replace("$_ = ServletIntegrationFactory.getInstance().getTransparentRealPath((RebelServletContext) $0, $1);");
}
}
});
}
}
↧
JRebel 6.4.2a Eclipse synchronization no longer works
Hi,
I upgraded my Eclipse plugin to 6.4.2a today and for some reason my project no longer gets synchronized automatically with my remote server. JRebel is configured with Synchronize on build and previously all I needed to do was to change and save a source code file and JRebel would trigger a sync automatically.
If I restart my server and manually trigger JRebel synchronize in Eclipse, it works only the first time. If I update the code, rebuild the Eclipse project and attempt a manual sync afterwards, I see the JRebel synchronization complete popup, but no trace of sync on the server side. I could only find the following in the jrebel-eclipse.log log file:
2016-04-08 14:31:45.704 INFO [Worker-43] RebelXmlGenerator - Generated rebel.xml in /...project/src/main/resources. Trigger: Invoked FULL_BUILD
2016-04-08 14:31:45.731 INFO [Worker-43] MonitoredDirectory - Disposing listener for dir /...project/build/classes/main
2016-04-08 14:31:45.731 INFO [Worker-43] MonitoredDirectory - Disposing listener for dir /...project/src/main/webapp
2016-04-08 14:31:45.732 INFO [Worker-43] RemotingProject - Conf is NULL, must do rebuild
My Specs:
IDE: Eclipse Mars.2 Release (4.5.2)
Eclipse Plugin: 6.4.2.SR1
Server: IBM Domino (64 Bit) (Release 9.0.1FP5HF140 for Linux/64)
Agent: JRebel Legacy Agent 6.4.2a (201604061405)
↧
Reply To: JRebel 6.4.2 breaks some Spring beans
Thanks, it works.
-
This reply was modified 34 minutes ago by
elmuerte.
↧
Reply To: JRebel 6.4.2a Eclipse synchronization no longer works
Hello Petrv!
Thanks a lot for the error stack trace! Could you please also send your trace level jrebel.log file from a remote server side after reproducing the issue to support@zeroturnaround.com with the link to this forum topic? You can find the instructions on how to generate that file here: http://manuals.zeroturnaround.com/jrebel/misc/sendinglogs.html. Also jrebel-eclipse.log from a client side would be helpful!
Kind regards,
Valerie
↧
↧
java.lang.AbstractMethodError [6.4.2a]
Hello,
I made an update of my JRebel to 6.4.2 and 6.4.2a.
I get some errors:
java.lang.AbstractMethodError: Method com/speedment/internal/core/manager/sql/AbstractSqlManager.getTable()Lcom/speedment/config/db/Table; is abstract
The code work fine without JRebel usage.
Full stack trace, it seems that JRebel do support all the code that tomcat do
java.lang.AbstractMethodError: Method com/speedment/internal/core/manager/sql/AbstractSqlManager.getTable()Lcom/speedment/config/db/Table; is abstract
at com.speedment.internal.core.manager.sql.AbstractSqlManager.getTable(AbstractSqlManager.java)
at com.speedment.internal.core.manager.sql.AbstractSqlManager.lambda$new$0(AbstractSqlManager.java:96)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at com.speedment.internal.core.manager.sql.AbstractSqlManager.<init>(AbstractSqlManager.java:98)
at com.ialoft.api.model.speedm.db.db0.application.generated.GeneratedApplicationManagerImpl.<init>(GeneratedApplicationManagerImpl.java:34)
at com.ialoft.api.model.speedm.db.db0.application.ApplicationManagerImpl.<init>(ApplicationManagerImpl.java:18)
at com.speedment.internal.core.runtime.SpeedmentApplicationLifecycle.applyAndPut(SpeedmentApplicationLifecycle.java:545)
at com.ialoft.api.model.speedm.generated.GeneratedSpeedmApplication.onLoad(GeneratedSpeedmApplication.java:33)
at com.speedment.component.Lifecyclable.load(Lifecyclable.java:132)
at com.speedment.internal.core.runtime.AbstractLifecycle.load(AbstractLifecycle.java:172)
at com.speedment.component.Lifecyclable.start(Lifecyclable.java:224)
at com.speedment.internal.core.runtime.AbstractLifecycle.start(AbstractLifecycle.java:182)
at com.speedment.internal.core.runtime.SpeedmentApplicationLifecycle.build(SpeedmentApplicationLifecycle.java:570)
at com.ialoft.api.CasualTest.test1(CasualTest.java:21)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)↧
Reply To: java.lang.AbstractMethodError [6.4.2a]
Hello Lamine!
Thanks a lot for the error stack trace! Could you please send your trace level jrebel.log file from a remote server side (you are still using remoting, right?) after reproducing the issue to support@zeroturnaround.com with the link to this forum topic? You can find the instructions on how to generate that file here: http://manuals.zeroturnaround.com/jrebel/misc/sendinglogs.html.
Also would be really helpful if you could send us your AbstractSqlManager, so we can reproduce the issue and fix it for you.
Kind regards,
Valerie
↧
Reply To: JRebel 6.4.2a Eclipse synchronization no longer works
Hi Valerie,
Thank you for the feedback! Upon further investigation I found out that this isn’t a JRebel problem after all. Eclipse was not rebuilding the project automatically after source code changes, so I recreated my .project and now it works fine again. AFAIC, no JRebel issue here.
↧
