Hello,
I got the same Exception and the initial cause was the following Exception:
[ClassLoaderManager] Unexpected error during load
of:javax.xml.stream.XMLEventReader: java.lang.LinkageError: loader constraint
violation: loader (instance of org/jboss/classloader/spi/base/BaseClassLoader)
previously initiated loading for a different type with name
"javax/xml/stream/XMLEventReader"
This Exception is not detailed enough to tell us about the real problem.
Usually such Exception should look like this, when occuring on runtime:
CLASS_A threw exception on object creation; nested exception is
java.lang.LinkageError: loader constraint violation in interface INTERFACE_X
initialization: when resolving method "CLASS_B.DO_SOMETHING(CLASS_C;)V" the
class loader (instance of SOME_CLASSLOADER) of the current class, CLASS_B, and
the class loader (instance of ANOTHER_CLASSLOADER) for interface INTERFACE_Y
have different Class objects for the type CLASS_C used in the signature.
After checking the dependencies of cloudsync, I saw, that there is no JAXB-API
supplied with the WAR - only the implementation. I think this dependency is
missing in your project. Because of that, classes of the JAXB-API are loaded by
another ClassLoader (parent ClassLoader or so) and the class
javax.xml.stream.XMLEventReader will be loaded by this ClassLoader as well.
When classes of the JAXB-IMPL are loaded from the cloudsync dependency because
of active isolation with parent_first=false, the class
javax.xml.stream.XMLEventReader will be loaded by the ClassLoader of the
cloudsync dependencies too and this results in conflict, when the
implementation is used by the API. If the API is part of the web application,
the same ClassLoader is being used to load those classes and there will be no
conflict.
After adding the JAXB-API (v2.1 because you use JAXB-IMPL v2.1.13) to
WEB-INF/lib I got the following Exception:
------------------------
ERROR [AbstractKernelController] Error installing to PostClassLoader:
name=vfs:///C:/eprojects/workspace/eSciDocCore-trunk/integration-tests/target/cargo/configurations/jboss6x/deploy/fcrepo-cloudsync-service-1.0.0-beta-2.war
state=ClassLoader mode=Manual requiredState=PostClassLoader:
org.jboss.deployers.spi.DeploymentException: Error during deploy:
vfs:///C:/eprojects/workspace/eSciDocCore-trunk/integration-tests/target/cargo/configurations/jboss6x/deploy/fcrepo-cloudsync-service-1.0.0-beta-2.war
at
org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
[:2.2.0.GA]
at
org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:185)
[:2.2.0.GA]
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832)
[:2.2.0.GA]
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550)
[:2.2.0.GA]
at
org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491)
[:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983)
[:2.2.0.GA]
at
org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076)
[:2.2.0.GA]
at
org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679)
[:2.2.0.GA]
at
org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106)
[:6.0.0.Final]
at
org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143)
[:0.2.2]
at
org.jboss.profileservice.dependency.ProfileDeployAction.deploy(ProfileDeployAction.java:151)
[:0.2.2]
at
org.jboss.profileservice.dependency.ProfileDeployAction.installActionInternal(ProfileDeployAction.java:94)
[:0.2.2]
at
org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
[jboss-kernel.jar:2.2.0.GA]
at
org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
[jboss-kernel.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654)
[jboss-dependency.jar:2.2.0.GA]
at
org.jboss.profileservice.dependency.ProfileActivationWrapper$BasicProfileActivation.start(ProfileActivationWrapper.java:190)
[:0.2.2]
at
org.jboss.profileservice.dependency.ProfileActivationWrapper.start(ProfileActivationWrapper.java:87)
[:0.2.2]
at
org.jboss.profileservice.dependency.ProfileActivationService.activateProfile(ProfileActivationService.java:215)
[:0.2.2]
at
org.jboss.profileservice.dependency.ProfileActivationService.activate(ProfileActivationService.java:159)
[:0.2.2]
at
org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.activate(AbstractProfileServiceBootstrap.java:112)
[:0.2.2]
at
org.jboss.profileservice.resolver.BasicResolverFactory$ProfileResolverFacade.deploy(BasicResolverFactory.java:87)
[:0.2.2]
at
org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.start(AbstractProfileServiceBootstrap.java:91)
[:0.2.2]
at
org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:132)
[:6.0.0.Final]
at
org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:56)
[:6.0.0.Final]
at
org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:827)
[jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
at
org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:417)
[jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Caused by: java.lang.Error: Error visiting
"/C:/eprojects/workspace/eSciDocCore-trunk/integration-tests/target/cargo/configurations/jboss6x/deployers/weld.deployer/lib-int/jboss-weld-int.jar/org/jboss/kernel/weld/plugins/metadata/WeldBeanMetaData.class"
at
org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:268)
[jboss-classloading-vfs.jar:2.2.0.GA]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:408)
[jboss-vfs.jar:3.0.0.GA]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:410)
[jboss-vfs.jar:3.0.0.GA]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:410)
[jboss-vfs.jar:3.0.0.GA]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:410)
[jboss-vfs.jar:3.0.0.GA]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:410)
[jboss-vfs.jar:3.0.0.GA]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:410)
[jboss-vfs.jar:3.0.0.GA]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:410)
[jboss-vfs.jar:3.0.0.GA]
at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:396)
[jboss-vfs.jar:3.0.0.GA]
at
org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:102)
[jboss-classloading-vfs.jar:2.2.0.GA]
at
org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.visit(VFSDeploymentClassLoaderPolicyModule.java:181)
[:2.2.0.GA]
at
org.jboss.scanning.plugins.DeploymentUnitScanner.scan(DeploymentUnitScanner.java:111)
[:1.0.0.GA]
at org.jboss.scanning.spi.helpers.UrlScanner.scan(UrlScanner.java:96)
[:1.0.0.GA]
at
org.jboss.scanning.deployers.ScanningDeployer.deploy(ScanningDeployer.java:95)
[:1.0.0.GA]
at
org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179)
[:2.2.0.GA]
... 43 more
Caused by: java.lang.RuntimeException: Error visiting resource:
VFSResourceContext @
org/jboss/kernel/weld/plugins/metadata/WeldBeanMetaData.class /
BaseClassLoader@164d9c7{vfs:///C:/eprojects/workspace/eSciDocCore-trunk/integration-tests/target/cargo/configurations/jboss6x/deploy/fcrepo-cloudsync-service-1.0.0-beta-2.war},
visitor: org.jboss.scanning.annotations.plugins.GenericAnnotationVisitor@15da57
at
org.jboss.scanning.plugins.visitor.IgnoreSetErrorHandler.handleError(IgnoreSetErrorHandler.java:56)
[:1.0.0.GA]
at
org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.visit(ReflectResourceVisitor.java:91)
[:1.0.0.GA]
at
org.jboss.scanning.annotations.plugins.AnnotationsScanningPlugin.visit(AnnotationsScanningPlugin.java:89)
[:1.0.0.GA]
at
org.jboss.scanning.spi.helpers.ScanningPluginWrapper.visit(ScanningPluginWrapper.java:112)
[:1.0.0.GA]
at
org.jboss.classloading.plugins.visitor.FederatedResourceVisitor.visit(FederatedResourceVisitor.java:101)
[jboss-classloading.jar:2.2.0.GA]
at
org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:264)
[jboss-classloading-vfs.jar:2.2.0.GA]
... 57 more
Caused by: java.lang.RuntimeException: Error retrieving annotation attribute
values
at
org.jboss.reflect.plugins.AnnotationValueFactory.createAnnotationValue(AnnotationValueFactory.java:124)
[jboss-reflect.jar:2.2.0.GA]
at
org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.createAnnotationValue(IntrospectionTypeInfoFactoryImpl.java:148)
[jboss-reflect.jar:2.2.0.GA]
at
org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getAnnotations(IntrospectionTypeInfoFactoryImpl.java:141)
[jboss-reflect.jar:2.2.0.GA]
at
org.jboss.reflect.plugins.InheritableAnnotationHolder.getDeclaredAnnotations(InheritableAnnotationHolder.java:96)
[jboss-reflect.jar:2.2.0.GA]
at
org.jboss.reflect.plugins.ClassInfoImpl.getAnnotations(ClassInfoImpl.java:181)
[jboss-reflect.jar:2.2.0.GA]
at
org.jboss.reflect.plugins.AbstractAnnotatedInfo.getUnderlyingAnnotations(AbstractAnnotatedInfo.java:63)
[jboss-reflect.jar:2.2.0.GA]
at
org.jboss.scanning.plugins.visitor.ClassHierarchyResourceVisitor.handleClass(ClassHierarchyResourceVisitor.java:76)
[:1.0.0.GA]
at
org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.doVisit(ReflectResourceVisitor.java:108)
[:1.0.0.GA]
at
org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.visit(ReflectResourceVisitor.java:86)
[:1.0.0.GA]
... 61 more
Caused by: java.lang.annotation.AnnotationTypeMismatchException: Incorrectly
typed data found for annotation element public abstract
javax.xml.bind.annotation.XmlNsForm
org.jboss.xb.annotations.JBossXmlSchema.elementFormDefault() (Found data of
type Ljavax/xml/bind/annotation/XmlNsForm;.QUALIFIED)
at
sun.reflect.annotation.AnnotationTypeMismatchExceptionProxy.generateException(AnnotationTypeMismatchExceptionProxy.java:38)
[:1.6.0_21]
at
sun.reflect.annotation.AnnotationInvocationHandler.invoke(AnnotationInvocationHandler.java:56)
[:1.6.0_21]
at $Proxy10.elementFormDefault(Unknown Source) at
sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source) [:1.6.0_21]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_21]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_21]
at
org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60)
[jboss-reflect.jar:2.2.0.GA]
at
org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168)
[jboss-reflect.jar:2.2.0.GA]
at
org.jboss.reflect.plugins.SecurityActions.invokeMethod(SecurityActions.java:78)
[jboss-reflect.jar:2.2.0.GA]
at
org.jboss.reflect.plugins.AnnotationValueFactory.createAnnotationValue(AnnotationValueFactory.java:117)
[jboss-reflect.jar:2.2.0.GA]
... 69 more
------------------------
Now the fun-part:
This Exception occurs, because the ClassLoader is loading the class
javax.xml.bind.annotation.XmlNsForm from the JAXB-API of the web application
instead of the jboss-jaxb-api (what we want to happen for our web application)
and this class conflicts with the one used in the class
org.jboss.kernel.weld.plugins.metadata.WeldBeanMetaData because the class
org.jboss.kernel.weld.plugins.metadata.WeldBeanMetaData requires the version
JBoss 6 delivers in jboss/lib/endorsed/jboss-jaxb-api.jar. The problem here is,
that the ResourceVisitor is visiting the Weld-Deployer and that happens,
because of existance of the WEB-INF/beans.xml.
See: http://docs.jboss.org/weld/reference/1.0.0/en-US/html/environments.html
To avoid the ResourceVisitor to visit the Weld-Deployer, you may rename your
WEB-INF/beans.xml.
Now, I am getting the following Exception:
Caused by: java.lang.RuntimeException: Neither any mapped-name/lookup/jndi-name
specified nor any ResourceProvider could process resource-env-ref named
env/org.apache.cxf.jaxrs.interceptor.AttachmentInputInterceptor/supportedTypes
of type java.util.List
I think I am going to take a break of all that now. :-)
---
Used isolation:
WEB-INF/jboss-classloading.xml:
<classloading xmlns="urn:jboss:classloading:1.0"
domain="someNameFooBar"
export-all="NON_EMPTY"
import-all="true"
parent-first="false">
</classloading>
WEB-INF/jboss-web.xml (old version for jboss4, but may work on later versions
too but with less configuration possibilities):
<jboss-web>
<class-loading>
<loader-repository>some.packagelike.name:loader=someName</loader-repository>
</class-loading>
</jboss-web>
Have fun and a nice weekend!
Marko Voß
ePublishing & eScience
Development & Applied Research
Phone +49 7247 808-744
Fax +49 7247 808-133
[email protected]
FIZ Karlsruhe – Leibniz Institute for Information Infrastructure
Hermann-von-Helmholtz-Platz 1
76344 Eggenstein-Leopoldshafen, Germany
www.fiz-karlsruhe.de
-----Original Message-----
From: Voß, Marko [mailto:[email protected]]
Sent: Friday, August 19, 2011 12:04 PM
To: [email protected]
Subject: Re: [fcrepo-dev] xalan, resteasy, activeMQ and JBoss
Hello Chris,
Yesterday, I successfully deployed eSciDoc and all other WARs we have to delpoy
as well (except for fedora.war because of Jersey) on JBoss 6 and we are using
CXF too. Some of the errors I got by trying to delpoy cloudsync.war may be
caused by the error prone delpoyments of our WARs, so I am now able to start
testing cloudsync.war without any possible site-effects.
JBoss 6 delivers its own CXF and your Exception could be caused by loading
classes from JBoss CFX instead of the ones, you are delivering in your
WEB-INF/lib directory. I had the same Exception once, so I guess a correct
isolation is all we need here.
> "[..] AS7's class loading is based on modules that have to define explicit
> dependencies on other modules. Deployments in AS7 are also modules, and do
> not have access to classes that are defined in jars in the application server
> unless an explicit dependency on those classes is defined."
It was about time, that the deployments are fully isolated by default like on
tomcat.
Kind regards,
Marko Voß
ePublishing & eScience
Development & Applied Research
Phone +49 7247 808-744
Fax +49 7247 808-133
[email protected]
FIZ Karlsruhe – Leibniz Institute for Information Infrastructure
Hermann-von-Helmholtz-Platz 1
76344 Eggenstein-Leopoldshafen, Germany
www.fiz-karlsruhe.de
-----Original Message-----
From: Chris Wilper [mailto:[email protected]]
Sent: Thursday, August 18, 2011 10:45 PM
To: [email protected]
Subject: Re: [fcrepo-dev] xalan, resteasy, activeMQ and JBoss
Well, I tried jboss-6.1.0-Final and got the following after attempting
to deploy:
DEPLOYMENTS IN ERROR:
Deployment
"vfs:///private/tmp/jboss-6.1.0.Final/server/default/deploy/cloudsync.war"
is in error due to the following reason(s):
java.lang.RuntimeException: Neither any mapped-name/lookup/jndi-name
specified nor any ResourceProvider could process resource-env-ref
named env/cxf of type org.apache.cxf.Bus
at
org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1370)
Not sure what exactly to make of that. But from what I can tell,
classloading is more sane by default in AS7:
https://docs.jboss.org/author/display/AS7/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7
In particular, I liked this part:
"[..] AS7's class loading is based on modules that have to define
explicit dependencies on other modules. Deployments in AS7 are also
modules, and do not have access to classes that are defined in jars in
the application server unless an explicit dependency on those classes
is defined."
Classloader isolation FTW!
Now to see if Fedora 3.5 will run in AS7...
- Chris
On Thu, Aug 18, 2011 at 4:01 PM, Chris Wilper <[email protected]> wrote:
> Hi Marko,
>
> Thanks for trying this. It inspired me to learn a bit about deploying
> on JBoss. But I've had different results so far; after doing a fresh
> installation of jboss-as-web-7.0.1.Final, I started jboss via
> bin/standalone.sh, then dropped cloudsync.war in
> standalone/deployments. Everything worked as expected.
>
> I understand that classloading works differently by default depending
> on the version of JBoss you have installed, so perhaps that explains
> the difference. I will also try JBoss 6 on this end and see if I can
> duplicate your results.
>
> Thanks,
> Chris
>
> On Wed, Aug 17, 2011 at 11:03 AM, Voß, Marko
> <[email protected]> wrote:
>> Hello Chris,
>>
>> I am trying to test your WAR on JBoss 6 but because of the missing isolation
>> (jboss-classloading.xml in the WEB-INF directory), I have to define the
>> isolation first, which could take some time before the classes are no longer
>> conflicting. With a default isolation I am currently getting this Exception:
>>
>> 16:53:25,359 WARN [ClassLoaderManager] Unexpected error during load
>> of:javax.xml.stream.XMLEventReader: java.lang.LinkageError: loader
>> constraint violation: loader (instance of
>> org/jboss/classloader/spi/base/BaseClassLoader) previously initiated loading
>> for a different type with name "javax/xml/stream/XMLEventReader"
>>
>> Without isolation I am getting a ClassCastException because classes are
>> loaded by different ClassLoaders from different deployments/delpoyers and
>> therefore their version may clash. So, before I can give you a response, I
>> have to get this running first.
>>
>>
>> Kind regards,
>>
>>
>> Marko Voß
>> ePublishing & eScience
>> Development & Applied Research
>> Phone +49 7247 808-744
>> Fax +49 7247 808-133
>> [email protected]
>>
>>
>> FIZ Karlsruhe – Leibniz Institute for Information Infrastructure
>> Hermann-von-Helmholtz-Platz 1
>> 76344 Eggenstein-Leopoldshafen, Germany
>>
>> www.fiz-karlsruhe.de
>>
>>
>> From: Chris Wilper [mailto:[email protected]]
>> Sent: Wednesday, August 17, 2011 3:52 PM
>> To: [email protected]
>> Subject: Re: [fcrepo-dev] xalan, resteasy, activeMQ and JBoss
>>
>> Hi Marko,
>> As I mentioned in the other thread, I think there is a distinct possibility
>> that we will move Fedora's JAX-RS implementation to CXF down the road. This
>> might be another good reason. I have used CXF for JAX-RS via Spring in
>> another project, and I did that in a way that I think could also work for
>> Fedora down the road. I am curious now whether the approach I used there
>> would work in JBoss 5+.
>>
>> Since you probably have a JBoss instance up and running, would you mind
>> giving it quick try? The download link and instructions can be found here:
>>
>> https://wiki.duraspace.org/display/FEDORACREATE/Fedora+CloudSync+Installation
>>
>> If this works in JBoss 5+, that would be good information to have, and could
>> help us make the decision to move to CXF for our JAX-RS impl down the road.
>>
>> To be clear, I think using approaches and libs that work with the widest
>> range of popular containers we can is a good thing. I am just wary of doing
>> too much that caters to any one specific container. This seems like an area
>> where we may be able to just use a different library and wiring mechanism
>> (which we were already thinking about), and achieve slightly better
>> compatibilty with a wider range of containers.
>>
>> Thanks,
>> Chris
>>
>> On Wed, Aug 17, 2011 at 7:38 AM, Voß, Marko <[email protected]>
>> wrote:
>> Hello,
>>
>> Next to the missing Xalan Implementation in Fedora deployed in JBoss
>> (depending on JBoss version and/or classloading isolation of the web
>> application), there is another problem with Fedora 3.4.2 deployed in Jboss
>> 5+.
>>
>> You will get an exception about the ResourceConfig not having any root
>> resource classes, because the package scanner of Jersey is scanning for
>> classes having the @Path annotation inside of the packages defined by the
>> param-values of the param-name configurations
>> "com.sun.jersey.config.property.packages" in the fedora.war/WEB-INF/web.xml
>> and since JBoss 5+ the classloader do support a VFS (virtual file system)
>> only. So the URLs returned by the classloaders consists of the scheme vfs:/
>> in JBoss 6 and because of that, the Jersey AnnotationClassScanner or the
>> Scanner implementations of the later Jersey versions are unable to find the
>> URLs, because they are checking for URLs with the schemes "file:/", "jar:/"
>> and so on but not for "vfs:/". In Jersey 1.3 this has been fixed for
>> schemes "vfsfile" and "vfszip" (iirc), which are schemes of JBoss 5, which
>> got changed to "vfs" in JBoss 6.
>>
>> To summarize this: It is impossible to get the Fedora RestService running in
>> JBoss 5 and later versions for Fedora 3.4.2.
>>
>> Possible solution: A possibility to get around the VFS URLs could be, to
>> write a class, which extends from javax.ws.rs.Application and defines the
>> REST interface for Fedora. Instead of defining packages to scan, you define
>> the param-name "javax.ws.rs.Application" with the implementing class as the
>> param-value in the fedora.war/WEB-INF/web.xml.
>>
>>
>> Kind regards,
>>
>> Marko Voß
>>
>> ePublishing & eScience
>> Development & Applied Research
>> Phone +49 7247 808-744
>>
>> Fax +49 7247 808-133
>> [email protected]
>>
>> FIZ Karlsruhe – Leibniz Institute for Information Infrastructure
>> Hermann-von-Helmholtz-Platz 1
>> 76344 Eggenstein-Leopoldshafen, Germany
>> www.fiz-karlsruhe.de
>> Fehler! Es wurde kein Dateiname angegeben.
>>
>>
>>
>> -------------------------------------------------------
>>
>> Fachinformationszentrum Karlsruhe, Gesellschaft für
>> wissenschaftlich-technische Information mbH.
>> Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB
>> 101892.
>> Geschäftsführerin: Sabine Brünger-Weilandt.
>> Vorsitzender des Aufsichtsrats: MinDirig Dr. Thomas Greiner.
>>
>> ------------------------------------------------------------------------------
>> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
>> user administration capabilities and model configuration. Take
>> the hassle out of deploying and managing Subversion and the
>> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
>> _______________________________________________
>> Fedora-commons-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>
>>
>>
>> -------------------------------------------------------
>>
>> Fachinformationszentrum Karlsruhe, Gesellschaft für
>> wissenschaftlich-technische Information mbH.
>> Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB
>> 101892.
>> Geschäftsführerin: Sabine Brünger-Weilandt.
>> Vorsitzender des Aufsichtsrats: MinDirig Dr. Thomas Greiner.
>>
>> ------------------------------------------------------------------------------
>> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
>> user administration capabilities and model configuration. Take
>> the hassle out of deploying and managing Subversion and the
>> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
>> _______________________________________________
>> Fedora-commons-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>
>
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
-------------------------------------------------------
Fachinformationszentrum Karlsruhe, Gesellschaft für wissenschaftlich-technische
Information mbH.
Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB
101892.
Geschäftsführerin: Sabine Brünger-Weilandt.
Vorsitzender des Aufsichtsrats: MinDirig Dr. Thomas Greiner.
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
-------------------------------------------------------
Fachinformationszentrum Karlsruhe, Gesellschaft für wissenschaftlich-technische
Information mbH.
Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB
101892.
Geschäftsführerin: Sabine Brünger-Weilandt.
Vorsitzender des Aufsichtsrats: MinDirig Dr. Thomas Greiner.
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
