Re: [jboss-dev-forums] [jBPM Development] - AttachmentTest failure
by Huisheng Xu
Huisheng Xu [http://community.jboss.org/people/rebody] replied to the discussion
"AttachmentTest failure"
To view the discussion, visit: http://community.jboss.org/message/539648#539648
--------------------------------------------------------------
Hi Maciej,
Thank you for yours help.
From your AttachmentTest-output.txt, I am afraid you are using JDK-1.6, because image/gif didn't find the DataContentHandler of image/gif. Between line 14 to 18, we could see the search result for image/gif.
18:10:48,976 FIN | [activation] MailcapCommandMap: createDataContentHandler for image/gif
18:10:48,976 FIN | [activation] search DB #1
18:10:48,976 FIN | [activation] search DB #2
18:10:48,976 FIN | [activation] search fallback DB #1
18:10:48,976 FIN | [activation] search fallback DB #2
If activation could find DataContentHandler, it will look like this, between line 10 to 13:
18:10:48,975 FIN | [activation] MailcapCommandMap: createDataContentHandler for text/plain
18:10:48,975 FIN | [activation] search DB #1
18:10:48,975 FIN | [activation] got content-handler
18:10:48,976 FIN | [activation] class com.sun.mail.handlers.text_plain
Because there are other testcase using javamail.jar, so I can't see the initialization information of mailcap. If you run AttachmentTest separately, you could see how it initialized.
I put my AttachmentTest-output.txt into attach. If you have time, please have a look at it. Thank you very much.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/539648#539648]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 11 months
[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...]
15 years, 11 months
Re: [jboss-dev-forums] [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...]
15 years, 11 months
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion
"ClassPool bootstrap refactoring"
To view the discussion, visit: http://community.jboss.org/message/539493#539493
--------------------------------------------------------------
AbstractMCServerBase now does (once it is working properly I will move the extra code to LifecycleEventListeners)
@Override
protected void doInitialize() throws IllegalStateException, InvalidConfigurationException, LifecycleEventException
{
// NEW CODE - 1
/*
* Make sure we have the correct classpools set up
*/
//Initialize jboss-reflect to use the correct classpools
JBossClClassPoolConfig config = JBossClClassPoolConfig.getInstance();
RepositoryClassPoolFactory factory = new RepositoryClassPoolFactory(config.getClassPoolRepository());
JavassistTypeInfoFactoryImpl.setPoolFactory(factory);
// NEW CODE - 1 - END
/*
* We need to start the bootstrap here so we can set the kernel
* before we fire start kernel events
*/
this.initializeBootstrap();
// Call Super implementation
super.doInitialize();
// NEW CODE - 2
//Install the bean configuring the classpools
BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder("JBossClClassPoolConfig", JBossClClassPoolConfig.class.getName());
builder.setFactoryClass(JBossClClassPoolConfig.class.getName());
builder.setFactoryMethod("getInstance");
ValueMetaData inject = builder.createContextualInject(null, null, AutowireType.BY_NAME, InjectOption.CALLBACK);
//TODO add name to BeanMetaDataBuilder
((AbstractInjectionValueMetaData)inject).setValue("ClassLoading");
builder.addPropertyMetaData("classLoading", inject);
try
{
getKernel().getController().install(builder.getBeanMetaData());
}
catch (Throwable e)
{
// AutoGenerated
throw new RuntimeException(e);
}
// NEW CODE - 2 - END
}
The stuff in 1) sets up the classloader system so it understands the bootstrap classloaders
The stuff in 2) "listens" for ClassLoading and registers the container as a module Handler
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/539493#539493]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 11 months
Re: [jboss-dev-forums] [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/539484#539484
--------------------------------------------------------------
Having revisited how the classpools are set up ( http://community.jboss.org/thread/151095 http://community.jboss.org/thread/151095) which became apparent after looking into ( http://community.jboss.org/message/538568#538568 http://community.jboss.org/message/538568#538568) and fixed the problems to do with generating accessors for classes loaded by a parent of the jboss-reflect classloader I now end up with the following problems when starting AS:
Failed to boot JBoss:
java.lang.Exception: Encountered exception in server startup
at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:360)
at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doStart(AbstractMCServerBase.java:292)
at org.jboss.bootstrap.impl.as.server.AbstractJBossASServerBase.doStart(AbstractJBossASServerBase.java:381)
at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:413)
at java.lang.Thread.run(Thread.java:637)
Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: java.lang.IllegalStateException: java.lang.ClassNotFoundException: org.jboss.beans.metadata.spi.AnnotationMetaData
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.annotations
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:195)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:175)
at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:161)
at org.jboss.bootstrap.impl.mc.deployer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:188)
at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:345)
... 4 more
Caused by: org.jboss.xb.binding.JBossXBRuntimeException: java.lang.IllegalStateException: java.lang.ClassNotFoundException: org.jboss.beans.metadata.spi.AnnotationMetaData
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.annotations
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment
at org.jboss.xb.builder.JBossXBNoSchemaBuilder.rethrowWithLocation(JBossXBNoSchemaBuilder.java:2293)
at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElementBinding(JBossXBNoSchemaBuilder.java:428)
at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElements(JBossXBNoSchemaBuilder.java:403)
at org.jboss.xb.builder.JBossXBNoSchemaBuilder.build(JBossXBNoSchemaBuilder.java:273)
at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:336)
at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:222)
at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:201)
at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:315)
at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:177)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.startElement(SaxJBossXBParser.java:370)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:191)
... 8 more
Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: java.lang.ClassNotFoundException: org.jboss.beans.metadata.spi.AnnotationMetaData
at org.jboss.reflect.plugins.javassist.JavassistParameterizedClassInfo.findTypeInfo(JavassistParameterizedClassInfo.java:153)
at org.jboss.reflect.plugins.javassist.JavassistParameterizedClassInfo.getComponentType(JavassistParameterizedClassInfo.java:121)
at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1447)
at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1231)
at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:855)
at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:843)
at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:604)
at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:563)
at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createElementBinding(JBossXBNoSchemaBuilder.java:443)
at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElementBinding(JBossXBNoSchemaBuilder.java:423)
... 28 more
Caused by: java.lang.IllegalStateException: java.lang.ClassNotFoundException: org.jboss.beans.metadata.spi.AnnotationMetaData
at org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.getTypeInfo(JavassistTypeInfoFactoryImpl.java:852)
at org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.createTypeInfoForTypeArgument(JavassistTypeInfoFactoryImpl.java:910)
at org.jboss.reflect.plugins.javassist.JavassistParameterizedClassInfo.getActualTypeArguments(JavassistParameterizedClassInfo.java:110)
at org.jboss.reflect.plugins.javassist.JavassistParameterizedClassInfo.findTypeInfo(JavassistParameterizedClassInfo.java:149)
... 37 more
Caused by: java.lang.ClassNotFoundException: org.jboss.beans.metadata.spi.AnnotationMetaData
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:315)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.delegateToIntrospectionImplementation(JavassistTypeInfoFactoryImpl.java:608)
at org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.get(JavassistTypeInfoFactoryImpl.java:564)
at org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.get(JavassistTypeInfoFactoryImpl.java:455)
at org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.get(JavassistTypeInfoFactoryImpl.java:412)
at org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.getTypeInfo(JavassistTypeInfoFactoryImpl.java:848)
... 40 more
Posting Shutdown Request to the server...
The problem here is for parameterized type infos. We currently use the type info of the raw type for the whole parameterized type which will not work for things like java.util.Set<org.jboss.beans.metadata.spi.AnnotationMetaData> since the raw type (Set) comes from the system classpath and thus cannot see the actual type argument classes (AnnotationMetaData is further down in the classloader hierarchy).
Parameterized type infos will need to be cached differently, I'll look at how these are handled in plain java across different classloaders.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/539484#539484]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 11 months
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - JBREFLECT-6 Skipping compilation step
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion
"JBREFLECT-6 Skipping compilation step"
To view the discussion, visit: http://community.jboss.org/message/539482#539482
--------------------------------------------------------------
Having revisited how the classpools are set up ( http://community.jboss.org/thread/151095 http://community.jboss.org/thread/151095) which became apparent after looking into ( http://community.jboss.org/message/538568#538568 http://community.jboss.org/message/538568#538568) I got some problems such as
10:59:48,915 WARN [PropertyConfiguration] Factory: org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactory@55ad6c98
XmlRootElement java.net.URLClassLoader@9a082e2
Failed to boot JBoss:
java.lang.Exception: Encountered exception in server startup
at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:360)
at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doStart(AbstractMCServerBase.java:292)
at org.jboss.bootstrap.impl.as.server.AbstractJBossASServerBase.doStart(AbstractJBossASServerBase.java:381)
at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:413)
at java.lang.Thread.run(Thread.java:637)
Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: java.lang.RuntimeException: Error retrieving annotation attribute values
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:195)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:175)
at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:161)
at org.jboss.bootstrap.impl.mc.deployer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:188)
at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:345)
... 4 more
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: Error retrieving annotation attribute values
at org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.getAnnotations(JavassistTypeInfoFactoryImpl.java:699)
at org.jboss.reflect.plugins.javassist.JavassistInheritableAnnotationHolder.getAnnotations(JavassistInheritableAnnotationHolder.java:78)
at org.jboss.reflect.plugins.javassist.JavassistTypeInfo.getAnnotations(JavassistTypeInfo.java:790)
at org.jboss.reflect.plugins.javassist.JavassistInheritableAnnotationHolder.getAnnotation(JavassistInheritableAnnotationHolder.java:91)
at org.jboss.reflect.plugins.AbstractAnnotatedInfo.getUnderlyingAnnotation(AbstractAnnotatedInfo.java:55)
at org.jboss.xb.builder.JBossXBBuilder.initSchema(JBossXBBuilder.java:351)
at org.jboss.xb.builder.JBossXBNoSchemaBuilder.build(JBossXBNoSchemaBuilder.java:271)
at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:336)
at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:222)
at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:201)
at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:315)
at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:177)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.startElement(SaxJBossXBParser.java:370)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:191)
... 8 more
Caused by: java.lang.RuntimeException: Error retrieving annotation attribute values
at org.jboss.reflect.plugins.AnnotationValueFactory.createAnnotationValue(AnnotationValueFactory.java:124)
at org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.getAnnotations(JavassistTypeInfoFactoryImpl.java:693)
... 32 more
Caused by: java.lang.RuntimeException: Error creating JavassistMethod for javax.xml.bind.annotation.XmlRootElement with classloader sun.misc.Launcher$AppClassLoader@517590db
at org.jboss.reflect.plugins.javassist.bytecode.JavassistMemberFactory.toClass(JavassistMemberFactory.java:316)
at org.jboss.reflect.plugins.javassist.bytecode.JavassistMemberFactory.makeClass(JavassistMemberFactory.java:289)
at org.jboss.reflect.plugins.javassist.bytecode.JavassistMemberFactory.createJavassistMethod(JavassistMemberFactory.java:197)
at org.jboss.reflect.plugins.javassist.JavassistReflectionFactory.createMethod(JavassistReflectionFactory.java:200)
at org.jboss.reflect.plugins.javassist.JavassistMethodInfo.invoke(JavassistMethodInfo.java:114)
at org.jboss.reflect.plugins.SecurityActions.invokeMethod(SecurityActions.java:78)
at org.jboss.reflect.plugins.AnnotationValueFactory.createAnnotationValue(AnnotationValueFactory.java:117)
... 33 more
Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/reflect/plugins/javassist/JavassistMethod
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:169)
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:136)
at org.jboss.reflect.plugins.javassist.bytecode.JavassistMemberFactory.toClass(JavassistMemberFactory.java:298)
... 39 more
Caused by: java.lang.NoClassDefFoundError: org/jboss/reflect/plugins/javassist/JavassistMethod
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:698)
at java.lang.ClassLoader.defineClass(ClassLoader.java:544)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javassist.util.proxy.FactoryHelper.toClass2(FactoryHelper.java:181)
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:163)
... 41 more
Caused by: java.lang.ClassNotFoundException: org.jboss.reflect.plugins.javassist.JavassistMethod
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:315)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:398)
... 49 more
This turned out to be due to javax.xml.bind.annotation.XmlRootElement coming from the system classloader while the jboss-reflect classes coming from a child classloader. It was set up to always use the classloader of the class we are creating an accessor for. I have changed it to still do that apart from if the class comes from a parent classloader of the jboss-reflect one, in which case we use the jboss-reflect classloader.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/539482#539482]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 11 months