[JBoss JIRA] (AS7-5331) @Resource UserTransaction should not be allowed in CMT beans
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/AS7-5331?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins edited comment on AS7-5331 at 1/25/13 9:15 AM:
---------------------------------------------------------------
Linked PR which replaces https://github.com/jbossas/jboss-as/pull/3213
was (Author: emmartins):
PR that replaces https://github.com/jbossas/jboss-as/pull/3213
> @Resource UserTransaction should not be allowed in CMT beans
> ------------------------------------------------------------
>
> Key: AS7-5331
> URL: https://issues.jboss.org/browse/AS7-5331
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Dominik Pospisil
> Assignee: jaikiran pai
>
> Currently, it seems then @Resource UserTransaction injection is allowed in CMT beans and injects
> container managed transaction. In AS/EAP5 this would throw an exception which I think is correct as
> this violates EJB 3.0 & 3.1 specs.
> Section 16.12 of the EJB 3.1 specification says:
> The container must make the UserTransaction interface available to the enterprise beans that are
> allowed to use this interface (only session and message-driven beans with bean-managed transaction
> demarcation are allowed to use this interface) either through injection using the Resource annotation
> or in JNDI under the name java:comp/UserTransaction, in addition to through the EJBContext
> interface. The authenticationType and shareable elements of the Resource annotation
> must not be specified.
> In my interpretation the statement "only session and message-driven beans with bean-managed transaction
> demarcation are allowed to use this interface" would mean that other beans are prohibited to use this
> interface. Allowing such beans to use this interface is specification violation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (AS7-6360) Mail subsystem transforms "tls" attribute by discarding it
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-6360?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar resolved AS7-6360.
------------------------------
Resolution: Done
fixed with migration to new transformer api which handles all this cases.
> Mail subsystem transforms "tls" attribute by discarding it
> ----------------------------------------------------------
>
> Key: AS7-6360
> URL: https://issues.jboss.org/browse/AS7-6360
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, Mail
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Fix For: 7.2.0.Alpha1
>
>
> The MailExtension registers a transformer that always discards the "tls" attribute. It should only discard if the value is consistent with the legacy slave's default behavior. Otherwise DiscardUndefinedAttribteTransformer should be used.
> Needs reject-expression transformation as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (JBRULES-3675) java.lang.LinkageError, but only sometimes (multithreading issue)
by kenneth westelinck (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3675?page=com.atlassian.jira.plug... ]
kenneth westelinck commented on JBRULES-3675:
---------------------------------------------
Well, that is not really possible. We have a fairly complex application with a large amount of rules being fired. And I am not allowed to send any code. However, we can reproduce it fairly easy on our side. So maybe you can add some more logging and I am willing to post you the output. Does this sound feasible?
> java.lang.LinkageError, but only sometimes (multithreading issue)
> -----------------------------------------------------------------
>
> Key: JBRULES-3675
> URL: https://issues.jboss.org/browse/JBRULES-3675
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core
> Affects Versions: 5.4.0.Final
> Environment: - JBoss 7.1.1
> - drools 5.4.0.Final
> - jdk 1.6u30
> - Windows 7 64 bit
> Reporter: kenneth westelinck
> Assignee: Mario Fusco
> Fix For: 6.0.0.Alpha1
>
>
> See mail on mailinglist:
> {noformat}
> We have an application (A) deployed on JBoss 7.1.1 accepting commands (CQRS,
> but only C and Q :) ). A console application (B) is sending a large volume
> of commands to create entities in A. Entities in A are validated by Drools
> (plain drl files, configured in spring using drools-spring). Most of the
> time this works just fine. But sometimes, we get the following exception:
> java.lang.LinkageError: loader (instance of
> org/drools/rule/JavaDialectRuntimeData$PackageClassLoader): attempted
> duplicate class definition for name:
> "a/b/c/Rule_person_unique___name_656ee3db19d34e689d95e2d6b2be67b6"
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_30]
> at org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:615) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:254) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:237) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader.loadClass(CompositeClassLoader.java:88) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:295) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [rt.jar:1.6.0_30]
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0InvokerGenerated.evaluate(Unknown Source)
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0Invoker.evaluate(Unknown Source)
> at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> Any idea where this is coming from or what's causing this.
> {noformat}
> And the answer:
> {noformat}
> I have never experienced this myself, but after having a quick look at the code I believe this could be a multi-threading problem.
> In the abstract class java.lang.ClassLoader the method loadClass(String, boolean) is synchronized, but both org.drools.util.CompositeClassLoader
> and org.drools.rule.JavaDialectRuntimeData$PackageClassLoader override this method without the use of "synchronized".
> I would suggest you create a JIRA issue for this.
> {noformat}
> We are now trying 5.5.0.CR1 and so far, we have not encountered this issue. I'll keep you posted should the same issue appear on 5.5.0.CR1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (JBRULES-3675) java.lang.LinkageError, but only sometimes (multithreading issue)
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3675?page=com.atlassian.jira.plug... ]
Mario Fusco commented on JBRULES-3675:
--------------------------------------
Could you post a test case or a small project that could allow me to reproduce this issue?
Thanks for your help,
Mario
> java.lang.LinkageError, but only sometimes (multithreading issue)
> -----------------------------------------------------------------
>
> Key: JBRULES-3675
> URL: https://issues.jboss.org/browse/JBRULES-3675
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core
> Affects Versions: 5.4.0.Final
> Environment: - JBoss 7.1.1
> - drools 5.4.0.Final
> - jdk 1.6u30
> - Windows 7 64 bit
> Reporter: kenneth westelinck
> Assignee: Mario Fusco
> Fix For: 6.0.0.Alpha1
>
>
> See mail on mailinglist:
> {noformat}
> We have an application (A) deployed on JBoss 7.1.1 accepting commands (CQRS,
> but only C and Q :) ). A console application (B) is sending a large volume
> of commands to create entities in A. Entities in A are validated by Drools
> (plain drl files, configured in spring using drools-spring). Most of the
> time this works just fine. But sometimes, we get the following exception:
> java.lang.LinkageError: loader (instance of
> org/drools/rule/JavaDialectRuntimeData$PackageClassLoader): attempted
> duplicate class definition for name:
> "a/b/c/Rule_person_unique___name_656ee3db19d34e689d95e2d6b2be67b6"
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_30]
> at org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:615) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:254) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:237) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader.loadClass(CompositeClassLoader.java:88) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:295) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [rt.jar:1.6.0_30]
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0InvokerGenerated.evaluate(Unknown Source)
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0Invoker.evaluate(Unknown Source)
> at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> Any idea where this is coming from or what's causing this.
> {noformat}
> And the answer:
> {noformat}
> I have never experienced this myself, but after having a quick look at the code I believe this could be a multi-threading problem.
> In the abstract class java.lang.ClassLoader the method loadClass(String, boolean) is synchronized, but both org.drools.util.CompositeClassLoader
> and org.drools.rule.JavaDialectRuntimeData$PackageClassLoader override this method without the use of "synchronized".
> I would suggest you create a JIRA issue for this.
> {noformat}
> We are now trying 5.5.0.CR1 and so far, we have not encountered this issue. I'll keep you posted should the same issue appear on 5.5.0.CR1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (AS7-6333) Add an id xml attribute to resource-adpter containing DMR resource name
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/AS7-6333?page=com.atlassian.jira.plugin.s... ]
Jesper Pedersen updated AS7-6333:
---------------------------------
Fix Version/s: 7.2.0.Alpha1
(was: 7.2.0.CR1)
Priority: Critical (was: Major)
> Add an id xml attribute to resource-adpter containing DMR resource name
> -----------------------------------------------------------------------
>
> Key: AS7-6333
> URL: https://issues.jboss.org/browse/AS7-6333
> Project: Application Server 7
> Issue Type: Task
> Components: JCA
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
> Priority: Critical
> Fix For: 7.2.0.Alpha1
>
>
> <xs:attribute name="id" type="xs:token" use="optional"><xs:annotation><xs:documentation>[
> An unique identifier for the resource adapter
> </xs:documentation></xs:annotation></xs:attribute>
> In case it is null resource name in DMR have to be generated (as now) and marshall in this attribute.
> This way also generated name will be consistent after a server reload
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (AS7-6393) Update commons-codec version to 1.6
by Josef Cacek (JIRA)
Josef Cacek created AS7-6393:
--------------------------------
Summary: Update commons-codec version to 1.6
Key: AS7-6393
URL: https://issues.jboss.org/browse/AS7-6393
Project: Application Server 7
Issue Type: Bug
Components: Test Suite
Reporter: Josef Cacek
Assignee: Josef Cacek
Apache HttpClient (4.2.1) library depends on commons-codec version 1.6, but we use only a version 1.4 now which is not fully compatible - e.g. changed behavior of the default constructor in Base64 class (chunked/not-chunked).
The problem is then in HttpClient's SPNEGO authentication.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (JBRULES-3675) java.lang.LinkageError, but only sometimes (multithreading issue)
by kenneth westelinck (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3675?page=com.atlassian.jira.plug... ]
kenneth westelinck commented on JBRULES-3675:
---------------------------------------------
No, that does not solve the issue. We encountered it again, even after synchronizing.
> java.lang.LinkageError, but only sometimes (multithreading issue)
> -----------------------------------------------------------------
>
> Key: JBRULES-3675
> URL: https://issues.jboss.org/browse/JBRULES-3675
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core
> Affects Versions: 5.4.0.Final
> Environment: - JBoss 7.1.1
> - drools 5.4.0.Final
> - jdk 1.6u30
> - Windows 7 64 bit
> Reporter: kenneth westelinck
> Assignee: Mario Fusco
> Fix For: 6.0.0.Alpha1
>
>
> See mail on mailinglist:
> {noformat}
> We have an application (A) deployed on JBoss 7.1.1 accepting commands (CQRS,
> but only C and Q :) ). A console application (B) is sending a large volume
> of commands to create entities in A. Entities in A are validated by Drools
> (plain drl files, configured in spring using drools-spring). Most of the
> time this works just fine. But sometimes, we get the following exception:
> java.lang.LinkageError: loader (instance of
> org/drools/rule/JavaDialectRuntimeData$PackageClassLoader): attempted
> duplicate class definition for name:
> "a/b/c/Rule_person_unique___name_656ee3db19d34e689d95e2d6b2be67b6"
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_30]
> at org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:615) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:254) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:237) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at org.drools.util.CompositeClassLoader.loadClass(CompositeClassLoader.java:88) [knowledge-api-5.4.0.Final.jar:5.4.0.Final]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:295) [rt.jar:1.6.0_30]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [rt.jar:1.6.0_30]
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0InvokerGenerated.evaluate(Unknown Source)
> at a.b.c.Rule_person___unique___name_656ee3db19d34e689d95e2d6b2be67b6Eval0Invoker.evaluate(Unknown Source)
> at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114) [drools-core-5.4.0.Final.jar:5.4.0.Final]
> Any idea where this is coming from or what's causing this.
> {noformat}
> And the answer:
> {noformat}
> I have never experienced this myself, but after having a quick look at the code I believe this could be a multi-threading problem.
> In the abstract class java.lang.ClassLoader the method loadClass(String, boolean) is synchronized, but both org.drools.util.CompositeClassLoader
> and org.drools.rule.JavaDialectRuntimeData$PackageClassLoader override this method without the use of "synchronized".
> I would suggest you create a JIRA issue for this.
> {noformat}
> We are now trying 5.5.0.CR1 and so far, we have not encountered this issue. I'll keep you posted should the same issue appear on 5.5.0.CR1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months