[JBoss Tools Development] - Remote Debugging for Eclipse Test Plug-in Running by Tycho
by Denis Golovin
Denis Golovin [http://community.jboss.org/people/dgolovin] modified the document:
"Remote Debugging for Eclipse Test Plug-in Running by Tycho"
To view the document, visit: http://community.jboss.org/docs/DOC-15209
--------------------------------------------------------------
When I report issue in bug tracking system about nightly build's JUnit test error I usually get simple answer that it is supposed to be working because it is working on developer's workstation. After that routine conversation starts and it turns out that tests were running from development environment under Eclipse. Here I usually have to explain again and again that's not the same running tests from development environment and in build.
The right way to make yourself sure your tests will work in most cases without errors in nightly build is to start tests the same way as nightly build does. It was not easy for JBoss Tools tests until we created experimental branch and switched to Maven Tycho project. That means it is fairly easy to run tests now. Basically you need to change current directory and execute maven install goal. If it runs in development environment and in maven your tests are good and in most cases it should be fine in nightly build. Problems begin if it runs in development environment but it doesn't in maven. In this scenario you need to debug tests running in Tycho somehow and fix it. Fortunately it can be done using Java remote debugging support.
First of all you need to be sure you have built your sources you're going to debug and there is no differences between .java and .class files. If you're going find problem from previous build just get right tagged version and build it before debugging session.
Then open pom.xml for your Eclipse Test Plug-in and add Java VM arguments like it shown below (actual port numbers, server names and other parameters may be different, it depends from your environment)
<build>
<plugins>
<plugin>
<groupid>org.sonatype.tycho</groupid>
<artifactid>maven-osgi-test-plugin</artifactid>
<version>${tycho-version}</version>
<configuration>
<argline>-Xdebug -Xrunjdwp:transport=dt_socket,address=8001,server=y,suspend=y</argline>
</configuration>
</plugin>
</plugins>
</build>
This snipped configured for remote debugging in OpenJDK 6, if your is different you might need to read #r1 [1] and configure it right for your JVM version.
Configure java projects with sources you're going to debug in Eclipse and create Remote Java Application configuration in Eclipse Debug Configuration dialog. Fill 'host' and 'port' fields with the same values from pom.xml argLine element. Press Apply button to save your changes and start your test plug-in from terminal like
$mvn install
It will go through build process and finally you ll see something like
[INFO] Expected eclipse log file: /home/eskimo/Projects/jbt-modular/jst/tests/org.jboss.tools.jst.web.kb.test/target/work/data/.metadata/.log
[INFO] Command line:
/bin/sh -c cd /home/eskimo/Projects/jbt-modular/jst/tests/org.jboss.tools.jst.web.kb.test && /usr/lib/jvm/java-6-openjdk/jre/bin/java -Dosgi.noShutdown=false -Dosgi.os=linux -Dosgi.ws=gtk -Dosgi.arch=x86 -agentlib:jdwp=transport=dt_socket,address=8001,server=y,suspend=y -jar /home/eskimo/.m2/repository/p2/osgi/bundle/org.eclipse.equinox.launcher/1.0.201.R35x_v20090715/org.eclipse.equinox.launcher-1.0.201.R35x_v20090715.jar -data /home/eskimo/Projects/jbt-modular/jst/tests/org.jboss.tools.jst.web.kb.test/target/work/data -dev file:/home/eskimo/Projects/jbt-modular/jst/tests/org.jboss.tools.jst.web.kb.test/target/dev.properties -install /home/eskimo/Projects/jbt-modular/jst/tests/org.jboss.tools.jst.web.kb.test/target/work -configuration /home/eskimo/Projects/jbt-modular/jst/tests/org.jboss.tools.jst.web.kb.test/target/work/configuration -application org.codehaus.tycho.surefire.osgibooter.uitest -testproperties /home/eskimo/Projects/jbt-modular/jst/tests/org.jboss.tools.jst.web.kb.test/target/surefire.properties
Listening for transport dt_socket at address: 8001
At this point build is waiting for you to attach remote debugger to the process because of using
suspend=y
in argLine element of your pom.xml file. So you need to return to eclipse and hit 'Debug' button in dialog opened before.
Build will continue at this point and stop on your break points so you can find out what is wrong with tests during nightly build.
[1] http://java.sun.com/javase/technologies/core/toolsapis/jpda/#Invocation Java Platform Debugger Architecture - http://java.sun.com/javase/technologies/core/toolsapis/jpda/#Invocation
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15209]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
16 years
Re: [jboss-user] [jBPM] - Process Variables made by Java cannot be deserialized
by Maciej Swiderski
Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion
"Process Variables made by Java cannot be deserialized"
To view the discussion, visit: http://community.jboss.org/message/539592#539592
--------------------------------------------------------------
Hi,
Huisheng is right, current patch does not solve the issue completely. Thanks to his test case I was able to reproduce it. Somehow context class loader is not enough.
I tried to reuse DeploymentClassLoader capabilities to solve the issue and it seems to work fine. In fact that was my first way of fixing it but I changed it to using only context class loader according to jira issue comments.
So I have a nice patch to upload but I have issues regarding source code structure:
- test case with process definition is placed in jbpm-test-db module
- since test case must deploy process definition with a class that is not available on class path it needs to be somewhere else as compiled resource I have put it at the moment into new folder (ext-resources) inside module jbpm-test-db
Please let me know if that is the right way to do it.
Cheers,
Maciej
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/539592#539592]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[JBoss Web Services CXF] - jBoss 5 and CXF 2.2.7
by Bruno Melloni
Bruno Melloni [http://community.jboss.org/people/bmelloni] created the discussion
"jBoss 5 and CXF 2.2.7"
To view the discussion, visit: http://community.jboss.org/message/539591#539591
--------------------------------------------------------------
We have been successfully using CXF 2.2.2 and 2.2.7 on jBoss 4.3 for about 9 months. Works beautifully on jBoss 4.3. It is simply a question of dropping the jars for cxf and its dependencies on our 'library' SAR where we put all open source libraries. Some of our apps absolutely require the NTLM authentication support included in 2.2.7.
jBoss 5 (EAP in our case, equivalent to the normal 5.1) includes CXF 2.2.2 but does not officially fully support it. Unfortunately, that seems worse than not including it at all. When I tried to deploy the 2.2.7 and a CXF-aware application in the same way as we did on jBoss 4.3, it drove jBoss nuts. CPU utilization went to 100% and jBoss ceased to function. We ended up having to reboot windows. My guess that the problem was caused by a conflict between CXF 2.2.7 and the 2.2.2 version included in jBoss.
Are we stuck with jBoss 4.3 and will have to wait until jBoss 5 gets an updated (2.2.7 or higher) and supported version of CXF? Or has somebody been successful at using a version of CXF higher than 2.2.2 on jBoss 5? Any hints would be greatly welcomed.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/539591#539591]
Start a new discussion in JBoss Web Services CXF at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [JBoss Microcontainer Development] - JBREFLECT-5 - Implementing generics in JavassistClassInfo
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion
"JBREFLECT-5 - Implementing generics in JavassistClassInfo"
To view the discussion, visit: http://community.jboss.org/message/539587#539587
--------------------------------------------------------------
After a few false starts I have managed to reproduce the error described in my last post, and while doing so found another problem to do with caching. Both of these problems are related and have to do with difficulties in determining the correct classloader to use for ParamerizedType.
1 - Other problem
> Kabir Khan wrote:
>
> > alesj wrote:
> >
> > As all of the stuff in Reflect works this way, why is this here a problem?
> Not really a problem, I just wanted to check if the object equality is required. It seems to work that way normally, so I'll do that for this instead as well.
The problem here is that if I generate some classes in classloader so they don't exist in the main classloader. I generate this set of classes twice in two different classloaders
public class SomeValue{}
public class SomeSignature
{
public java.util.Set<SomeValue> signature
{
return null;
}
}
I generate the classes twice, now if I do something along the lines of
public void testClasses()
{
ClassInfo infoA = getSignatureMethodReturnTypeForClass(loaderA); //One of the loaders loading the classes
ClassInfo infoB = getSignatureMethodReturnTypeForClass(loaderB); //Another loader loading the classes
//These all pass
assertEquals(ClassLoader.getSystemClassLoader(), infoA.getRawType().getClassLoader());
assertEquals(ClassLoader.getSystemClassLoader(), infoB.getRawType().getClassLoader());
assertEquals(loaderA, infoA.getActualTypeArguments[0].getClassLoader());
//Fails - loader is loaderA
assertEquals(loaderB, infoB.getActualTypeArguments[0].getClassLoader());
}
private void getSignatureMethodReturnTypeForClass(ClassLoader loader)
{
generateClasses(getPoolForLoader(loader));
Class clazz = loader.loadClass("SomeSignature");
Method m = loader.getMethod("signature");
Type t = m.getGenericReturnType(); //instance of java.lang.reflect.ParameterizedType
return getTypeInfoFactory().getTypeInfo(t);
}
The reason this fails is that the parameterized classinfo is cached against the string representation of the name, i.e. "java.lang.String<SomeValue>". This fails with both the introspection and javassist implementations.
The root of the problem is this in the entry point to both implementations of TypeInfoFactory, and that ParameterizedType has no getClassLoader() method, so it is currently guessed by defaulting to the one for the raw type. The implementations look something like
public TypeInfo getTypeInfo(Type type)
{
if (type == null)
throw new IllegalArgumentException("Null type");
if (type instanceof ParameterizedType)
return getParameterizedType((ParameterizedType) type);
...
}
public void getParameterizedType(ParameterizedType type)
{
//Check cache
ClassLoader loader = type.getRawType().getClassLoader(); // 1
TypeInfo cached = checkLoaderCacheForParameterizedType(loader, getName(type));
if (cached != null)
return true;
//Create parameterized type wrapper
TypeInfo rawType = getTypeInfo(type.getRawType());
TypeInfo args = new TypeInfo[type.getActualTypeArguments().length];
for (int i = 0 ; i < args.length ; i++)
{
args[i] = getTypeInfo(type.getActualTypeArguments()[i];
}
ClassInfo info = createParameterizedClassInfo(rawType, args);
//Cache the lookup
cacheParameterizedTypeForLoader(loader, info);
return info;
}
So what happens is when we try to get the parameterized type for Set<SomeValue> with loaderA it gets cached, but against the classloader of Set, which is the system classloader. When we try to get it with loaderB, it is found, but from the cache for Set's classloader, i.e. the system classloader.
So maybe caching should be turned off for parameterized types? I have not yet checked what the implications of this would be, but it would mean that object equality checks if used will not work for parameterized types created this way. Or maybe they should be cached against the context classloader instead?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/539587#539587]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years