[JBoss JIRA] (WFLY-9020) Wildfly 10 - JPA Entity deserialization problem on @Transient field
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9020?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned WFLY-9020:
---------------------------------
Assignee: (was: David Lloyd)
> Wildfly 10 - JPA Entity deserialization problem on @Transient field
> -------------------------------------------------------------------
>
> Key: WFLY-9020
> URL: https://issues.jboss.org/browse/WFLY-9020
> Project: WildFly
> Issue Type: Bug
> Components: Application Client
> Affects Versions: 10.0.0.Final
> Environment: Windows 7, Eclipselink 2.6.4 integration, Widlfly 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Priority: Minor
>
> In Wildfly 10,
> We have some system tests that sporadically fail when the client of the application loads an entity, connected to other sub-entities, where one of these sub-entities has a @Transient field.
> In Particular, we have an entity Attributes that has a field of the form:
> {panel}
> @Transient
> private Map<String, String> attributeMap = new TreeMap<String, String>();
> {panel}
> The root cause of the deserialization problem is of the form:
> {panel}
> Caused by: an exception which occurred:
> in object of type java.util.TreeMap
> in field attributeMap
> in object of type basepackage.entity.Attributes
> in field attributes
> in object of type basepackage.entity.SubEntityB
> in element at index [0] of size [1]
> in field delegate
> in object of type org.eclipse.persistence.internal.indirection.jdk8.IndirectList
> in field loadUnits
> in object of type basepackage.entity.ParentEntityA
> {panel}
> The de-serialization execution stack looks as follows:
> {panel}
> Caused by: java.io.OptionalDataException
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:147)
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:135)
> at org.jboss.marshalling.MarshallerObjectInputStream.readObjectOverride(MarshallerObjectInputStream.java:53)
> at org.jboss.marshalling.river.RiverObjectInputStream.readObjectOverride(RiverObjectInputStream.java:307)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:367)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2567)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2583)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2508)
> at java.util.TreeMap.readObject(TreeMap.java:2454)
> at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:307)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:180)
> at org.jboss.marshalling.river.RiverUnmarshaller.readCollectionData(RiverUnmarshaller.java:776)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:675)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.jboss.ejb.client.remoting.MethodInvocationResponseHandler$MethodInvocationResultProducer.getResult(MethodInvocationResponseHandler.java:104)
> {panel}
> We are using the following cliean library:
> {panel}
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-client-all</artifactId>
> <version>10.0.0.Final</version>
> <scope>test</scope>
> <optional>true</optional>
> <exclusions>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-commons</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-core-client</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-jms-client</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-hqclient-protocol</artifactId>
> </exclusion>
> <exclusion>
> <groupId> org.slf4j</groupId>
> <artifactId>jcl-over-slf4j</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> {panel}
> Currently no sample application exists to reproduce the issue.
> On weblogic the deserialization process goes without incident.
> Could the @Transient annotation and the eventual (empty map vs popuated attribtues map) play a role on this issue?
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-6673) JTA does not set transaction timeout for XAResource for propagated transactions
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-6673?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-6673:
-----------------------------------
I think this is fixed now in WildFly 11 and later?
> JTA does not set transaction timeout for XAResource for propagated transactions
> -------------------------------------------------------------------------------
>
> Key: WFLY-6673
> URL: https://issues.jboss.org/browse/WFLY-6673
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Reporter: Ondra Chaloupka
> Assignee: David Lloyd
>
> I can see a fact that transaction timeout is not provided by subordinate transaction when passed by ejb remote call when JTA transaction are used.
> Even when transaction timeout is defined (it could be seen that timeout is used when xaresources is used on client) the server where transaction is propagated shows xa resources using the default timeou value.
> Client server (caller) - timeout is _6 seconds_
> {code}
> 2016-05-19 11:50:51,461 TRACE [com.arjuna.ats.jta] (default task-18) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:TestXAResource(TestXAResourceCommon(id:483, xid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:57a802d4:573d8c57:20, subordinatenodename=null, eis_name=java:/TestXAResource-483 >, timeout:6, prepareReturn:0)), txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:57a802d4:573d8c57:20, subordinatenodename=null, eis_name=java:/TestXAResource-483 >, heuristic: TwoPhaseOutcome.FINISH_OK, product: Crash Recovery Test/EAP Test, jndiName: java:/TestXAResource-483 com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@7b44816f >, record id=0:ffff7f000001:57a802d4:573d8c57:21
> {code}
> Server (callee) - uses timeout _0 seconds_
> {code}
> 2016-05-19 11:50:39,374 TRACE [com.arjuna.ats.jta] (default task-12) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:TestXAResource(TestXAResourceCommon(id:502, xid:< formatId=131077, gtrid_length=29, bqual_length=37, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:3b603de1:573d8c5f:17, subordinatenodename=2, eis_name=java:/TestXAResource-502 >, timeout:0, prepareReturn:0)), txid:< formatId=131077, gtrid_length=29, bqual_length=37, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:3b603de1:573d8c5f:17, subordinatenodename=2, eis_name=java:/TestXAResource-502 >, heuristic: TwoPhaseOutcome.FINISH_OK, product: Crash Recovery Test/EAP Test, jndiName: java:/TestXAResource-502 com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@4f35ed3f >, record id=0:ffff7f000001:3b603de1:573d8c5f:18
> {code}
> Scenario that I'm running is
> # enlist jms xa resource on client
> # call to second server, it means enlist ejb remoting xa resource to transaction
> # enlist test xa on server
> # enlist jms xa resource on server
> # enlist test xa on client
> # starting 2PC
> # prepare jms xa resource on server
> # prepare ejb remoting xa resource on server
> # prepare test xa resource on client
> # transaction timeout is hit
> # if underlying jms resource timeouts then XAResource.prepare call fails with XAER_NOTA and the whole transaction is rolled back
> #
> _(attaching server.log files for EAP 7.0.0/Narayana 5.2.16.Final where jbossts is caller and jbossts2 is callee)_
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9942) Remove hornetq-native and -journal dependencies
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-9942?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil edited comment on WFLY-9942 at 3/2/18 9:32 AM:
-----------------------------------------------------------
It turns out that the dependencies are actually required:
{code}
org.wildfly:wildfly-feature-pack:pom:13.0.0.Alpha1-SNAPSHOT
org.hornetq:hornetq-core-client:jar:2.4.7.Final:compile has transitive dependencies:
org.hornetq:hornetq-journal:jar:2.4.7.Final:compile
org.jboss.logging:jboss-logging:jar:3.3.1.Final:compile
org.hornetq:hornetq-native:jar:2.4.7.Final:compile
{code}
hornetq-core-client depends on hornetq-journal to reference some constants...
was (Author: jmesnil):
It turns out that the dependencies are actually required:
[code]
org.wildfly:wildfly-feature-pack:pom:13.0.0.Alpha1-SNAPSHOT
org.hornetq:hornetq-core-client:jar:2.4.7.Final:compile has transitive dependencies:
org.hornetq:hornetq-journal:jar:2.4.7.Final:compile
org.jboss.logging:jboss-logging:jar:3.3.1.Final:compile
org.hornetq:hornetq-native:jar:2.4.7.Final:compile
[code]
hornetq-core-client depends on hornetq-journal to reference some constants...
> Remove hornetq-native and -journal dependencies
> -----------------------------------------------
>
> Key: WFLY-9942
> URL: https://issues.jboss.org/browse/WFLY-9942
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> WildFly pom.xml and its feature-pack still have dependencies for hornetq-native and hornet-journal jars.
> They are no longer used (since they were only required when HornetQ broker was integrated) and should be removed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9942) Remove hornetq-native and -journal dependencies
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-9942?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-9942:
-----------------------------------
It turns out that the dependencies are actually required:
[code]
org.wildfly:wildfly-feature-pack:pom:13.0.0.Alpha1-SNAPSHOT
org.hornetq:hornetq-core-client:jar:2.4.7.Final:compile has transitive dependencies:
org.hornetq:hornetq-journal:jar:2.4.7.Final:compile
org.jboss.logging:jboss-logging:jar:3.3.1.Final:compile
org.hornetq:hornetq-native:jar:2.4.7.Final:compile
[code]
hornetq-core-client depends on hornetq-journal to reference some constants...
> Remove hornetq-native and -journal dependencies
> -----------------------------------------------
>
> Key: WFLY-9942
> URL: https://issues.jboss.org/browse/WFLY-9942
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> WildFly pom.xml and its feature-pack still have dependencies for hornetq-native and hornet-journal jars.
> They are no longer used (since they were only required when HornetQ broker was integrated) and should be removed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9941) :shutdown cli operation throws java.util.concurrent.CancellationException: Operation was cancelled
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFLY-9941?page=com.atlassian.jira.plugin.... ]
Jean-Francois Denise commented on WFLY-9941:
--------------------------------------------
I am not familiar with Manu. Could you point me where the CLI is involved?
Thanks.
JF
> :shutdown cli operation throws java.util.concurrent.CancellationException: Operation was cancelled
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-9941
> URL: https://issues.jboss.org/browse/WFLY-9941
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 12.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jean-Francois Denise
> Attachments: manu-trace.log
>
>
> There is intermittent failure on CLI client when CLI operation {{ :shutdown() }} is called. Sometimes happens that CancellationException is thrown:
> {code}
> 2018-03-01 09:36:59,188 ERROR pool-1-thread-1 org.jboss.manu.eap.services.server.EapModularServerBase - Can't stop server gracefully
> java.io.IOException: java.util.concurrent.CancellationException: Operation was cancelled
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) ~[wildfly-controller-client-2.0.0.CR5.jar:2.0.0.CR5]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) ~[wildfly-controller-client-2.0.0.CR5.jar:2.0.0.CR5]
> at org.wildfly.extras.creaper.core.online.OnlineManagementClientImpl.execute(OnlineManagementClientImpl.java:180) ~[creaper-core-1.6.1.jar:na]
> at org.jboss.manu.eap.services.server.EapModularServerBase.executeOnlineManagementOperation(EapModularServerBase.java:600) ~[manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.eap.services.server.EapModularServerBase.executeOnlineManagementOperation(EapModularServerBase.java:638) ~[manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.eap.services.server.EapServerStandalone.executeStopOperation(EapServerStandalone.java:348) ~[manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.eap.services.server.EapModularServerBase.stop(EapModularServerBase.java:238) ~[manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.eap.units.server.StopServer.execute(StopServer.java:57) [manu-eap-lib-1.1.54.jar:na]
> at org.jboss.manu.core.execute.UnitExecuteTask.call(UnitExecuteTask.java:33) [manu-core-impl-1.1.43.jar:na]
> at org.jboss.manu.core.execute.UnitExecuteTask.call(UnitExecuteTask.java:14) [manu-core-impl-1.1.43.jar:na]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_151]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_151]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_151]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
> Caused by: java.util.concurrent.CancellationException: Operation was cancelled
> at org.jboss.threads.AsyncFutureTask.operationCancelled(AsyncFutureTask.java:70) ~[jboss-threads-2.2.1.Final.jar:2.2.1.Final]
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:267) ~[jboss-threads-2.2.1.Final.jar:2.2.1.Final]
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:57) ~[wildfly-controller-client-2.0.0.CR5.jar:2.0.0.CR5]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) ~[wildfly-controller-client-2.0.0.CR5.jar:2.0.0.CR5]
> ... 13 common frames omitted
> {code}
> WF12 server shutdowns but it seems that it does not send response for {{:shutdown}} call to client before shutdwon and closes connection. This causes that AsyncFutureTask on client is cancelled.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3562) Deployment disable-all doesn't correct function at domain
by Vratislav Marek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3562?page=com.atlassian.jira.plugi... ]
Vratislav Marek commented on WFCORE-3562:
-----------------------------------------
Preparing tests for coverage issue.
> Deployment disable-all doesn't correct function at domain
> ---------------------------------------------------------
>
> Key: WFCORE-3562
> URL: https://issues.jboss.org/browse/WFCORE-3562
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Vratislav Marek
> Assignee: Martin Stefanko
> Attachments: app01.war, app02.war, app03.war
>
>
> Domain
> {noformat}
> [domain@localhost:9990 /] deployment disable-all --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain@localhost:9990 /]
> {noformat}
> {noformat}
> [domain@localhost:9990 /] undeploy * --keep-content --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain@localhost:9990 /]
> {noformat}
> {noformat}
> [domain@localhost:9990 /] deployment disable-all --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
> (\"server-group\" => \"main-server-group\"),
> (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain@localhost:9990 /]
> {noformat}
> {noformat}
> [domain@localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
> (\"server-group\" => \"main-server-group\"),
> (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain@localhost:9990 /]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-3335) JAXB transformer initiation
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3335?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved WFLY-3335.
-------------------------------
Resolution: Done
I'll assume it's fixed. If someone encounters this issue again, it can be reopened or a new issue filed. Thanks.
> JAXB transformer initiation
> ---------------------------
>
> Key: WFLY-3335
> URL: https://issues.jboss.org/browse/WFLY-3335
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.0.0.Final, 8.1.0.CR1
> Environment: Ubuntu 14.04 with java 7 openjdk
> Reporter: Ghet Ghetolay
> Assignee: David Lloyd
> Priority: Critical
>
> I'm not directly using JAXB and SaxTransformer, it's part of a the [dcm4chee-arc project|https://github.com/dcm4che/dcm4chee-arc] which I tried to use on Wildfly. It's a rather big and complicated project so I've create a test application to illustrate the bug. I've used a JAR-RS application to illustrate the bug (like the original case) but this should not be related to it.
> {code:title=TestRS.java}
> @Path("test")
> public class TestRS {
>
> private static SAXTransformerFactory factory =
> (SAXTransformerFactory) TransformerFactory.newInstance();
>
> @GET
> public Response test(){
> try {
> Templates template = factory.newTemplates(new StreamSource(
> TestRS.class.getResource("json_compact.xsl").toString()));
>
> factory.newTransformerHandler(template);
>
> } catch (TransformerConfigurationException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> return Response.ok().build();
> }
> }
> {code}
> {code:title=json_compact.xsl}
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
> <xsl:output method="text"/>
> <xsl:template match="/">
> <xsl:text>Test</xsl:text>
> </xsl:template>
> </xsl:stylesheet>
> {code}
> {quote}
> 15:24:48,564 ERROR [stderr] (default task-1) javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 15:24:48,564 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:369)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:383)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:418)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformerHandler(TransformerFactoryImpl.java:1062)
> 15:24:48,565 ERROR [stderr] (default task-1) at __redirected.__TransformerFactory.newTransformerHandler(__TransformerFactory.java:193)
> 15:24:48,566 ERROR [stderr] (default task-1) at test.TestRS.test(TestRS.java:25)
> {quote}
> I've discovered that the initial exception is :
> {quote}
> java.lang.NoClassDefFoundError: com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet
> {quote}
> Both my test case and dcm4che-arc project works fine on JBoss 7.1.1.Final.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-1372) CompositeIndexProcessor::calculateModuleIndex does not respect import filters
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1372?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-1372:
-------------------------------------
Ah okay, I was misreading the code.
> CompositeIndexProcessor::calculateModuleIndex does not respect import filters
> -----------------------------------------------------------------------------
>
> Key: WFCORE-1372
> URL: https://issues.jboss.org/browse/WFCORE-1372
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Alessio Soldano
> Assignee: David Lloyd
>
> I have a deployment whose manifest declares
> {noformat}Dependencies: org.foo annotations{noformat}
> What I'm trying to do with the org.foo module is basically filtering (and exposing) a subset of the org.apache.cxf.impl module. To achieve that, I have the following module.xml:
> {noformat}
> <module xmlns="urn:jboss:module:1.3" name="org.foo">
> <resources>
> </resources>
> <dependencies>
> <module name="org.apache.cxf.impl" services="import">
> <imports>
> <include path="META-INF/cxf"/>
> <include path="META-INF"/>
> <include path="org/apache/cxf/sts"/>
> <include path="org/apache/cxf/sts/**"/>
> <include path="org/apache/cxf/ws/security/sts/**"/>
> </imports>
> <exports>
> <include path="META-INF/cxf"/>
> <include path="META-INF"/>
> <include path="org/apache/cxf/sts"/>
> <include path="org/apache/cxf/sts/**"/>
> <include path="org/apache/cxf/ws/security/sts/**"/>
> </exports>
> </module>
> <module name="asm.asm" />
> <module name="javax.api" />
> <module name="javax.annotation.api" />
> <module name="javax.validation.api"/>
> <module name="javax.jms.api" />
> <module name="javax.jws.api" />
> <module name="javax.mail.api" />
> <module name="javax.resource.api" />
> <module name="javax.servlet.api" />
> <module name="javax.wsdl4j.api" />
> <module name="javax.xml.bind.api" services="import"/>
> <module name="com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider"/>
> <module name="com.sun.xml.bind" services="import"/>
> <module name="javax.xml.soap.api" />
> <module name="javax.xml.stream.api" />
> <module name="javax.xml.ws.api" />
> <module name="javax.ws.rs.api" />
> <module name="org.apache.commons.lang" />
> <module name="org.apache.httpcomponents"/>
> <module name="org.apache.neethi" />
> <module name="org.apache.velocity" />
> <module name="org.apache.xml-resolver" />
> <module name="org.apache.ws.xmlschema" />
> <module name="org.apache.ws.security" />
> <module name="org.apache.santuario.xmlsec" />
> <module name="org.codehaus.jettison" />
> <module name="org.codehaus.woodstox" />
> <module name="org.joda.time" />
> <module name="org.opensaml" />
> </dependencies>
> </module>
> {noformat}
> The problem I'm having is that the composite annotation index that's attached to my deployment includes annotations from org.apache.cxf.impl module classes that are not included in the imports/exports above.
> To me, this is due to the CompositeIndexProcessor::calculateModuleIndex(Module module) method that uses PathFilters.getDefaultImportFilter() (instead of my filters) for adding stuff to the index.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months