LinkageError: loader constraint violation - BundleClassLoader - docx4j - apache-felix

Am using org.docx4j.Docx4J in a desktop application (JDK1.8) for converting WORD file to PDF and it all works fine.
The same desktop application, when launched as an OSGi plug-in (JDK1.8), throws NoClassDefFoundError: javax/xml/bind/JAXBException for the above mentioned conversion.
Upon adding the below dependencies:
implementation group: 'org.docx4j', name: 'docx4j-JAXB-Internal', version: '8.2.8'
implementation group: 'org.docx4j', name: 'docx4j-JAXB-ReferenceImpl', version: '8.2.8'
implementation group: 'org.docx4j', name: 'docx4j-JAXB-MOXy', version: '8.2.8'
I get the below error (in bold):
java.lang.linkageerror: loader constraint violation: when resolving interface method "javax.xml.stream.XMLStreamReader.getNamespaceContext()Ljavax/xml/namespace/NamespaceContext;"
the class loader "" (instance of org.apache.felix.framework.BundleWiringImpl$BundleClassLoader#2dd2e270,
child of sun.misc.Launcher$AppClassLoader#277050dc) of the current class, org/eclipse/persistence/internal/oxm/record/namespaces/UnmarshalNamespaceContext,
and the class loader for the method's defining class, javax/xml/stream/XMLStreamReader,
have different Class objects for the type javax/xml/namespace/NamespaceContext used in the signature
java.lang.linkageerror: loader constraint violation: when resolving interface method "javax.xml.stream.XMLStreamReader.getNamespaceContext()Ljavax/xml/namespace/NamespaceContext;"
the class loader "<unnamed>" (instance of org.apache.felix.framework.BundleWiringImpl$BundleClassLoader#2dd2e270,
child of sun.misc.Launcher$AppClassLoader#277050dc) of the current class, org/eclipse/persistence/internal/oxm/record/namespaces/UnmarshalNamespaceContext,
and the class loader <bootstrap> for the method's defining class, javax/xml/stream/XMLStreamReader,
have different Class objects for the type javax/xml/namespace/NamespaceContext used in the signature
at org.eclipse.persistence.internal.oxm.record.namespaces.UnmarshalNamespaceContext.getPrefix(UnmarshalNamespaceContext.java:58)
at org.eclipse.persistence.internal.oxm.record.UnmarshalRecordImpl.resolveNamespaceUri(UnmarshalRecordImpl.java:1338)
at org.eclipse.persistence.internal.oxm.SAXFragmentBuilder.startElement(SAXFragmentBuilder.java:78)
at org.eclipse.persistence.internal.oxm.XMLRelationshipMappingNodeValue.setupHandlerForKeepAsElementPolicy(XMLRelationshipMappingNodeValue.java:231)
at org.eclipse.persistence.internal.oxm.XMLAnyObjectMappingNodeValue.startElement(XMLAnyObjectMappingNodeValue.java:179)
at org.eclipse.persistence.internal.oxm.record.UnmarshalRecordImpl.startElement(UnmarshalRecordImpl.java:864)
at org.eclipse.persistence.internal.oxm.record.XMLStreamReaderReader.parseEvent(XMLStreamReaderReader.java:138)
at org.eclipse.persistence.internal.oxm.record.XMLStreamReaderReader.parse(XMLStreamReaderReader.java:102)
at org.eclipse.persistence.internal.oxm.record.XMLStreamReaderReader.parse(XMLStreamReaderReader.java:89)
at org.eclipse.persistence.internal.oxm.record.SAXUnmarshaller.unmarshal(SAXUnmarshaller.java:940)
at org.eclipse.persistence.internal.oxm.XMLUnmarshaller.unmarshal(XMLUnmarshaller.java:655)
at org.eclipse.persistence.jaxb.JAXBUnmarshaller.unmarshal(JAXBUnmarshaller.java:637)
at org.docx4j.convert.in.FlatOpcXmlImporter.<init>(FlatOpcXmlImporter.java:132)
Per the suggestions, when i add just these three to my plug-in bundle:
implementation group: 'javax.xml.bind', name: 'jaxb-api', version: '2.3.1'
implementation group: 'org.docx4j', name: 'docx4j-JAXB-ReferenceImpl', version: '8.2.8'
implementation group: 'javax.xml.stream', name: 'stax-api', version: '1.0-2'
i have:
ClassCastException: com.ctc.wstx.stax.WstxInputFactory (loaded by sun.misc.Launcher$AppClassLoader#0x0000000100046e00) cannot be cast to javax.xml.stream.XMLInputFactory
(loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader#0x0000000100240038)
(found matching super class javax.xml.stream.XMLInputFactory loaded by , but needed loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader#0x0000000100240038)
at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136)
at org.docx4j.convert.in.FlatOpcXmlImporter.<init>(FlatOpcXmlImporter.java:115)
I really hope someone from DOCX4J and/or APACHE FELIX kindly help me out. All of this has to do with bundle class loading!

You need to add a dependency for the JAXB-API, because it is no longer part of modern JREs:
implementation group: 'javax.xml.bind', name: 'jaxb-api', version: '2.3.1'
In addition, you need to add one (and only one) of the three dependencies you added. The first one is probably not going to work, because of the removal of JAXB, so I would go for the second one:
implementation group: 'org.docx4j', name: 'docx4j-JAXB-ReferenceImpl', version: '8.2.8'
Remove the two other dependencies you added.

Related

Quarkus native build Random/SplittableRandom exception with Vert.x Redis Client

I am doing a native build of my Quarkus app and am hitting the UnsupportedFeatureException: Detected an instance of Random/SplittableRandom on a few Vertx Redis Client classes.
I am building using the docker container method:
./mvnw package -Dnative -Dquarkus.native.container-build=true
I have fixed some of the exceptions by including in the pom.xml:
<quarkus.native.additional-build-args>
--initialize-at-run-time=io.vertx.redis.client.impl.RedisSentinelClient
</quarkus.native.additional-build-args>
but am stuck on this one:
Fatal error: com.oracle.graal.pointsto.util.AnalysisError$ParsingError: Error encountered while parsing
io.vertx.redis.client.impl.RedisClusterConnection.send(io.vertx.redis.client.Request)
Parsing context:
at io.vertx.redis.client.impl.RedisClusterConnection.send(RedisClusterConnection.java:117)
at io.vertx.redis.client.impl.BaseRedisClient.lambda$send$1(BaseRedisClient.java:45)
at io.vertx.redis.client.impl.BaseRedisClient$$Lambda$1711/0x00000007c1ea57e8.apply(Unknown Source)
I have tried adding
--initialize-at-run-time=io.vertx.redis.client.impl.RedisSentinelClient\,io.vertx.redis.client.impl.RedisClusterConnection
--initialize-at-run-time=io.vertx.redis.client.impl.RedisSentinelClient\,io.vertx.redis.client.impl.BaseRedisClient
and even
--initialize-at-run-time=io.vertx.redis.client.impl.RedisSentinelClient\,io.vertx.redis.client.impl.RedisReplicationConnection.send(io.vertx.redis.client.Request)
but the error persists.
I am fairly new to Java and very new to native building / GraalVM etc
Can anyone shed any light on what class I should add, please?
Thanks,
Murray
I believe we can propose a change to vert.x redis client to avoid the split random use. The randomness is there mostly to share the load across nodes. It is not used for any security related features. For this reason, a proposal to either round-robin would probably make more sense as a solution to this issue.
Ok, this seems to fix it:
EDIT: No it doesn't. See below.
<quarkus.native.additional-build-args>
--initialize-at-run-time=io.vertx.redis.client.impl.RedisSentinelClient\,io.vertx.redis.client.impl.RedisReplicationConnection
</quarkus.native.additional-build-args>
The full profiles section in the pom.xml looks like this, for anyone else new to all this.
<profiles>
<profile>
<id>native</id>
<activation>
<property>
<name>native</name>
</property>
</activation>
<properties>
<skipITs>false</skipITs>
<quarkus.package.type>native</quarkus.package.type>
<quarkus.native.additional-build-args>
--initialize-at-run-time=io.vertx.redis.client.impl.RedisSentinelClient\,io.vertx.redis.client.impl.RedisReplicationConnection
</quarkus.native.additional-build-args>
</properties>
</profile>
</profiles>
I have different errors now, so still not building, but at least this seems to fix that specific issue.
EDIT: The problem persists...
If I build with the pom as described above, ie:
<quarkus.native.additional-build-args>
--initialize-at-run-time=io.vertx.redis.client.impl.RedisSentinelClient\,io.vertx.redis.client.impl.RedisReplicationConnection
</quarkus.native.additional-build-args>
I now get:
Error: Classes that should be initialized at run time got initialized during image building:
io.vertx.redis.client.impl.RedisReplicationConnection
the class was requested to be initialized at run time
(from command line with 'io.vertx.redis.client.impl.RedisReplicationConnection').
So, I guess that is not the right class afterall.
If I remove that class from the list I revert to the Random exception.
(Showing more detail)
[1/7] Initializing... (3.7s # 0.10GB)
Version info: 'GraalVM 22.3.1.0-Final Java 17 Mandrel Distribution'
Java version info: '17.0.6+10'
C compiler: gcc (linux, x86_64, 11.3.0)
Garbage collector: Serial GC
4 user-specific feature(s)
- io.quarkus.runner.Feature: Auto-generated class by Quarkus from the existing extensions
- io.quarkus.runtime.graal.DisableLoggingFeature: Disables INFO logging during the analysis phase for the [org.jboss.threads] categories
- io.quarkus.runtime.graal.ResourcesFeature: Register each line in META-INF/quarkus-native-resources.txt as a resource on Substrate VM
- io.quarkus.websockets.client.runtime.DisableLoggingFeature: Disables INFO logging during the analysis phase for the [io.undertow.websockets] categories
[2/7] Performing analysis... [*] (14.1s # 3.37GB)
12,032 (89.58%) of 13,432 classes reachable
17,778 (59.65%) of 29,803 fields reachable
61,621 (57.16%) of 107,809 methods reachable
541 classes, 150 fields, and 2,655 methods registered for reflection
Fatal error: com.oracle.graal.pointsto.util.AnalysisError$ParsingError: Error encountered while parsing io.vertx.redis.client.impl.RedisReplicationConnection.send(io.vertx.redis.client.Request)
Parsing context:
at io.vertx.redis.client.impl.RedisReplicationConnection.send(RedisReplicationConnection.java:111)
at io.vertx.redis.client.RedisConnection.send(RedisConnection.java:83)
at io.vertx.redis.client.impl.RedisReplicationClient.getNodes(RedisReplicationClient.java:183)
at io.vertx.redis.client.impl.RedisReplicationClient.lambda$connect$4(RedisReplicationClient.java:126)
at io.vertx.redis.client.impl.RedisReplicationClient$$Lambda$2203/0x00000007c1630f60.handle(Unknown Source)
at io.vertx.core.impl.future.FutureImpl$1.onSuccess(FutureImpl.java:91)
{etc}
I am beginning to think I have an error / issue in my code where I am using the Vert.x Redis Client. I am trying to narrow it down by trial and error.
Any other suggestions are most welcome.

Spring Boot Geode Unsatisfied dependency expressed through method 'sessionRegion'

The correct dependencies for my gradle.build are driving me crazy!
In order to access an Apache Geode 1.10 server, I am using:
// Geode client dependency
implementation 'org.springframework.geode:spring-geode-starter:1.2.13.RELEASE'
implementation 'org.springframework.data:spring-data-geode:2.2.12.RELEASE'
implementation 'org.springframework.boot:spring-boot-starter-tomcat:2.2.13.RELEASE'
This fails with the error:
org.springframework.context.support.AbstractApplicationContext 596 refresh:
Exception encountered during context initialization - cancelling refresh attempt:
org.springframework.beans.factory.UnsatisfiedDependencyException:
Error creating bean with name 'ClusteredSpringSessions' defined in class path resource
[org/springframework/session/data/gemfire/config/annotation/web/http/GemFireHttpSessionConfiguration.class]:
Unsatisfied dependency expressed through method 'sessionRegion' parameter 0;
nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'org.springframework.data.gemfire.config.annotation.ClientCacheConfiguration':
Initialization of bean failed; nested exception is java.lang.IllegalAccessError:
class org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$703/0x0000000801025d10
tried to access protected method 'boolean org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport.hasValue(java.lang.Number)'
(org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$703/0x0000000801025d10
and org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport are in unnamed module of loader 'app')
What is there to tell me the dependency missing for the UnsatisfiedDependencyException for 'ClusteredSpringSessions'?
If I remove the #EnableGemFireHttpSession annotation then I get the error
2021-02-02T19:29:49,011 WARN [main] org.springframework.context.support.AbstractApplicationContext 596 refresh:
Exception encountered during context initialization - cancelling refresh attempt:
org.springframework.beans.factory.UnsatisfiedDependencyException:
Error creating bean with name 'cacheManager' defined in class path resource [org/springframework/data/gemfire/cache/config/GemfireCachingConfiguration.class]:
Unsatisfied dependency expressed through method 'cacheManager' parameter 0;
nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'org.springframework.data.gemfire.config.annotation.ClientCacheConfiguration':
Initialization of bean failed; nested exception is java.lang.IllegalAccessError:
class org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$679/0x00000008010306b8
tried to access protected method 'boolean org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport.hasValue(java.lang.Number)'
(org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$679/0x00000008010306b8
and org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport are in unnamed module of loader 'app')
What is there to tell me the dependency missing for the UnsatisfiedDependencyException for 'cacheManager'?
Thanks
UPDATE The App is run like Spring Boot #ComponentScan finds candidate component class but does not inject #Configuration beans but more specifically
#SpringBootApplication
#ComponentScan({"api", "rsocket", "pricing", "listeners", "dealing", "web"}) // scans packages for # components
#EnableLogging(logLevel="debug", logFile="geodeApi.log")
public class Api {
private static final Logger log = LogManager.getLogger(Api.class);
public static void main(String[] args) {
log.info("In Main");
SpringApplication app = new SpringApplication(Api.class);
app.setWebApplicationType(WebApplicationType.REACTIVE);
SpringApplication.run(Api.class, args);
log.info("Out Main");
}
}
The component scan finds various #Component annotated classes for example
#Component
#EnableClusterDefinedRegions(clientRegionShortcut=ClientRegionShortcut.PROXY)
public class ClientCache {
private static final Logger log = LogManager.getLogger(ClientCache.class);
#Resource
private Region<String, String> admin;
#Autowired
LQuote lQuote;
#Autowired
LReject lReject;
#Autowired
LDeal lDeal;
#Autowired
DealNumber dealNumber;
#Autowired
PriceService priceService;
#PreDestroy
public void onDestroy() throws Exception {
log.info("onDestroy");
String guid = UUID.randomUUID().toString().substring(0, 8).toUpperCase();
admin.put(guid, "API Shutdown");
// TODO: Cancel all open quote streams
log.traceExit();
}
#Bean
ApplicationRunner StartedUp(){
log.traceEntry("StartedUp");
return args -> {
String guid = UUID.randomUUID().toString().substring(0, 8).toUpperCase();
admin.put(guid, "API Started");
lQuote.addListener();
lReject.addListener();
lDeal.addListener();
// Get latest deal number
int currentId = dealNumber.readCurrentId();
// Set it + 1 in case the web server was reboot on the fly
priceService.setCurrentId(currentId + 1);
log.traceExit();
};
}
A lot of the problem was using Java JDK version 15.
The correct versions require Java 11.
// Geode client dependency
implementation 'org.springframework.geode:spring-geode-starter:1.2.8.RELEASE'
implementation 'org.springframework.data:spring-data-geode:2.2.8.RELEASE'
implementation 'org.springframework.boot:spring-boot-starter-tomcat'
Technically, it is not necessary to explicitly declare the SDG dependency.
The SBDG dependency (i.e. org.springframework.geode:spring-geode-starter) already includes SDG (org.springframework.data:spring-data-geode). You can follow the dependency trail starting here, then here and finally, here.
As the Version Compatibility Matrix for SBDG specifies, SBDG 1.2.13.RELEASE specifically includes, and is based on, SDG 2.2.12.RELEASE (already), which is (technically) based on Apache Geode 1.9.2.
However, if you need to use Apache Geode 1.10, then you could (recommended) simply declare dependency management to enforce the use of Apache Geode 1.10 in your Gradle build:
plugins {
id 'org.springframework.boot' version '2.2.13.RELEASE'
id 'io.spring.dependency-management' version '1.0.10.RELEASE'
id 'java'
}
dependencyManagement {
dependencies {
dependency 'org.apache.geode:geode-core:1.10.0'
dependency 'org.apache.geode:geode-cq:1.10.0'
dependency 'org.apache.geode:geode-lucene:1.10.0'
dependency 'org.apache.geode:geode-wan:1.10.0'
}
}
dependencies {
implementation 'org.springframework.geode:spring-geode-starter:1.2.13.RELEASE`
implementation 'org.springframework.boot:spring-boot-starter-tomcat'
}
...
WARNING: SDG 2.2.12.RELEASE is officially based on Apache Geode 1.9.2, and though it should work reasonably well with Apache Geode 1.10, there could expectedly be limitations in certain use cases.
This is not unlike what Spring Initializer conveniently generates for you. Of course, Spring Initializer now uses the new SBDG BOM that makes managing individual SBDG module dependencies even easier, which is not unlike how Spring Boot's dependency management manages transitive dependencies, including 3rd party libs.
Regarding the Exceptions...
It really seems to me like you are having configuration problems rather than dependency problems, actually.
Of course, it is hard to say for certain given you shared very minimal Gradle build configuration and no code snippets from your Spring Boot application configuration, only mentions and what I am able to derive from the Exception messages. So, for now, I'll proceed based on what you provided and what I know or could derive.
Looking at this part of the (first) Exception message:
Error creating bean with name 'ClusteredSpringSessions' defined in class path resource
[org/springframework/session/data/gemfire/config/annotation/web/http/GemFireHttpSessionConfiguration.class]:
Unsatisfied dependency expressed through method 'sessionRegion' parameter 0
And, specifically:
Unsatisfied dependency expressed through method 'sessionRegion' parameter 0
This message refers to the (Spring Java) configuration provided by SSDG and imported/auto-configured by SBDG.
The "Unsatisfied dependency", or "parameter 0", is the 1st method parameter in the sessionRegion(..) (Spring JavaConfig-based) #Bean definition method declared in SSDG's configuration. It is the dependency on the GemFire cache instance (e.g. ClientCache) required to create the "ClusteredSpringSessions" Region.
So now, the question becomes, how is the cache created?
Well, this is what the framework is trying to do next... resolve the cache bean dependency (instance reference), which necessary triggers the cache creation first (due to dependency order)...
Error creating bean with name 'org.springframework.data.gemfire.config.annotation.ClientCacheConfiguration':
Initialization of bean failed; nested exception is java.lang.IllegalAccessError
We see that an IllegalAccessError occurred (O.o) which already smells like a version problem to me, but...
The ClientCacheConfiguration is provided by SDG.
Finally, we arrive at the underlying cause...
class org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$703/0x0000000801025d10
tried to access protected method 'boolean org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport.hasValue(java.lang.Number)'
NOTE: ClientCacheConfiguration extends AbstractCacheConfiguration, which extends AbstractAnnotationConfigSupport, and therefore should have "access" to the protected hasValue(:Number) method.
The main Thread appears to be in one of these Lambdas where the AbstractAnnotationConfig.hasValue(:Number) method is used.
I am no entirely sure what this means...
org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$703/0x0000000801025d10
and org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport are in unnamed module of loader 'app'
Are you possibly using Spring Boot's new (Layered) Docker Image support by chance?
The 2nd Exception message (involving the cacheManager bean this time) leads to the same outcome, actually. It is no different, but simply involves another bean (i.e. cacheManager bean) with the same dependency on the cache instance:
Error creating bean with name 'cacheManager' defined in class path resource
[org/springframework/data/gemfire/cache/config/GemfireCachingConfiguration.class]
: Unsatisfied dependency expressed through method 'cacheManager' parameter 0;
nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'org.springframework.data.gemfire.config.annotation.ClientCacheConfiguration':
Initialization of bean failed; nested exception is java.lang.IllegalAccessError:
class org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$679/0x00000008010306b8
tried to access protected method 'boolean org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport.hasValue(java.lang.Number)'
(org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$679/0x00000008010306b8
and org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport are in unnamed module of loader 'app')
And, specifically:
Initialization of bean failed; nested exception is java.lang.IllegalAccessError:
tried to access protected method 'boolean org.springframework.data.gemfire
.config.annotation.support.AbstractAnnotationConfigSupport
.hasValue(java.lang.Number)'
And:
(org.springframework.data.gemfire.config.annotation.AbstractCacheConfiguration$$Lambda$679/0x00000008010306b8
and org.springframework.data.gemfire.config.annotation.support.AbstractAnnotationConfigSupport
are in unnamed module of loader 'app')
I am not familiar with this error messages (basically, said class(es) "are in unnamed module of loader 'app'.") What?
How is this Spring Boot app being run?
Definitely providing a sample app, one or more tests, your configuration, logs, Stack Traces in addition to Exception messages, setup, runtime environment, etc, etc, will go along way in trying to understand the context of this problem.
At this point, I am really trying to point you in a direction to start untangling the problem.
Sorry, I cannot (currently) be of more help in this case.

No Runnable Methods and Test Class Should Have Exactly One Public Constructor Exception

I can't seem to shake this error. The Eclipse Runner appears to find the #Test annotations however the BlockJUnit4ClassRunner validateConstructor and validateInstanceMethods can't see the #Test annotations.
I have read In this case, Test.class have been loaded with the system ClassLoader (i.e. the one that loaded JUnitCore), therefore technically none of the test methods will have been annotated with that annotation.
Solution is to load JUnitCore in the same ClassLoader as the tests themselves.
I've tried updating the JUnitCore in the same ClassLoader however missed the exact configuration. I have also tried an external runner along with try/catch to consume the error.. Nothing appears to work.
How would I...
Junit Runner to identify the class,
or
Possibly Ignore this error in a try/catch
or
Implement the correct structure for the ClassLoader solution?
I've attached a copy of code in git repository reference. bhhc.java throws the exception upon execution.
Supported Data:
SRC: https://github.com/agolem2/MavenJunit/blob/master/src/Test/bhhc.java
ERROR:
Google
Completed Test Case bhhc Date: 2017-09-26 08_57_17.318
Test run was NOT successful:
No runnable methods - Trace: java.lang.Exception: No runnable methods
org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4Cl
assRunner.java:191)
org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUni
t4ClassRunner.java:128)
Test class should have exactly one public constructor - Trace:
java.lang.Exception: Test class should have exactly one public constructor
org.junit.runners.BlockJUnit4ClassRunner.validateOnlyOneConstructor(BlockJUnit
4ClassRunner.java:158)
org.junit.runners.BlockJUnit4ClassRunner.validateConstructor(BlockJUnit4ClassR
unner.java:147)

D2FS within workflow method

I´m trying to use D2FS services within a workflow method, but im getting the following error:
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2 counts of IllegalAnnotationExceptions
Two classes have the same XML type name "address". Use #XmlType.name and #XmlType.namespace to assign different names to them.
this problem is related to the following location:
at com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Address
at public com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Address com.sun.xml.ws.developer.MemberSubmissionEndpointReference.addr
at com.sun.xml.ws.developer.MemberSubmissionEndpointReference
this problem is related to the following location:
at javax.xml.ws.wsaddressing.W3CEndpointReference$Address
at private javax.xml.ws.wsaddressing.W3CEndpointReference$Address javax.xml.ws.wsaddressing.W3CEndpointReference.address
at javax.xml.ws.wsaddressing.W3CEndpointReference
Two classes have the same XML type name "elements". Use #XmlType.name and #XmlType.namespace to assign different names to them.
this problem is related to the following location:
at com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Elements
at public com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Elements com.sun.xml.ws.developer.MemberSubmissionEndpointReference.referenceProperties
at com.sun.xml.ws.developer.MemberSubmissionEndpointReference
this problem is related to the following location:
at javax.xml.ws.wsaddressing.W3CEndpointReference$Elements
at private javax.xml.ws.wsaddressing.W3CEndpointReference$Elements javax.xml.ws.wsaddressing.W3CEndpointReference.referenceParameters
at javax.xml.ws.wsaddressing.W3CEndpointReference
I tried to update the jaxws-rt libraries and started getting the new error:
java.lang.LinkageError: ClassException: attempting to castjar:file:/C:/Documentum/jboss4.3.0/server/DctmServer_MethodServer/deploy/bpm.ear/APP-INF/lib/jaxws-api.jar!/javax/xml/ws/spi/Provider.classtojar:file:/C:/Documentum/jboss4.3.0/jdk/jre/lib/rt.jar!/javax/xml/ws/spi/Provider.class
at javax.xml.ws.spi.Provider.provider(Provider.java:94)
at javax.xml.ws.Service.<init>(Service.java:56)
at com.emc.d2fs.schemas.models.ModelPortService.<init>(ModelPortService.java:46)
at com.emc.cgd.methodsWorkflow.DispatchExtStorageUpdateData.doTask(DispatchExtStorageUpdateData.java:45)
at com.documentum.bpm.rtutil.WorkflowMethod.execute(WorkflowMethod.java:214)
at com.documentum.bpm.rtutil.AbstractWorkflowMethod.executeMethod(AbstractWorkflowMethod.java:27)
at com.documentum.bpm.rtutil.GenericWorkflowMethod.execute(GenericWorkflowMethod.java:124)
at com.documentum.bpm.rtutil.GenericWorkflowMethod.execute(GenericWorkflowMethod.java:65)
at com.documentum.mthdservlet.DfMethodRunner.runIt(Unknown Source)
at com.documentum.mthdservlet.AMethodRunner.runAndReturnStatus(Unknown Source)
Any idea how to solve it?
Im using:
JBoss 4.3
JAX-WS Implementation 2.2
Thanks
On tomcat I had to add following jars to the tomcat lib:
jaxws-api.jar
jaxws-rt.jar
stax-ex.jar
streambuffer.jar
Perhaps this will resolver the problem on jBoss as well.

OpenEJB tries to bind a remote EJB twice

I am having a strange issue regarding OpenEJB and integration tests.
I am using Open EJB 4.5.1, JUnit 4.10 and Maven3 with surefire plugin 2.13
I start OpenEJB from my test doing:
InitialContext ic = new InitialContext();
It works (apparently) fine and deploys the EJB (CentrosBeanFacade) correctly, but after that it tries to bind it again, which causes the server to fail.
These are the interesting log parts:
First time --> [OK] :
DEBUG - bound ejb at name: openejb/Deployment/CentrosBeanFacade/com.csc.health.xhis.arqtest.api.CentrosLogica, ref: org.apache.openejb.core.ivm.naming.BusinessRemoteReference#6506fe2b
DEBUG - bound ejb at name: openejb/Deployment/CentrosBeanFacade/com.csc.health.xhis.arqtest.api.CentrosLogica!Remote, ref: org.apache.openejb.core.ivm.naming.BusinessRemoteReference#6506fe2b
INFO - Jndi(name=CentrosBeanFacade) --> Ejb(deployment-id=CentrosBeanFacade)
INFO - Jndi(name=global/classpath.ear/test-ejb/CentrosBeanFacade!com.csc.health.xhis.arqtest.api.CentrosLogica) --> Ejb(deployment-id=CentrosBeanFacade)
INFO - Jndi(name=global/classpath.ear/test-ejb/CentrosBeanFacade) --> Ejb(deployment-id=CentrosBeanFacade)
But then it tries to deploy it a second time.
DEBUG - failed to bind ejb at name: openejb/Deployment/CentrosBeanFacade/com.csc.health.xhis.arqtest.api.CentrosLogica, ref: org.apache.openejb.core.ivm.naming.BusinessRemoteReference#32f00d9a
ERROR - Jndi name could not be bound; it may be taken by another ejb. Jndi(name=openejb/Deployment/CentrosBeanFacade/com.csc.health.xhis.arqtest.api.CentrosLogica!Remote)
The internal BusinessRemoteReference from EJB is a different object than the first time, so it is trying to deploy it a second time. But I have checked the classpath and the EJB is not included twice. If I execute a similar procedure but from a plain Java class, it also fails.
Any clues?