[JBoss JIRA] (AS7-2166) Alternative JDKs for building and running - OpenJDK 6, 7, Sun JDK 7, IcedTea
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-2166?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-2166:
----------------------------------------------
Rostislav Svoboda <rsvoboda(a)redhat.com> made a comment on [bug 899644|https://bugzilla.redhat.com/show_bug.cgi?id=899644]
Update for EAP 6.1.0 ER2:
Failure happens constantly on OpenJDK 7, random failure on Oracle JDK 7.
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-WS/j...
> Alternative JDKs for building and running - OpenJDK 6, 7, Sun JDK 7, IcedTea
> ----------------------------------------------------------------------------
>
> Key: AS7-2166
> URL: https://issues.jboss.org/browse/AS7-2166
> Project: Application Server 7
> Issue Type: Sub-task
> Components: Test Suite
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
> Labels: eap6_prd_req
> Fix For: 7.1.2.Final (EAP)
>
>
> James Perkins:
> {quote}
> At one point there was a JIRA for OpenJDK 6, in fact I think a couple. The issue with OpenJDK 6 is in the build we use some JavaScript and OpenJDK 6 doesn't come with a JavaScript engine. I tried a couple things to get Rhino working with it as that's what the Sun JDK uses, but I think it needs to implement an SPI to get it to work. I didn't look into it much beyond that.
> JDK 7 is a different issue. It's a bug in the annotation processing API which the JBoss Logging Tooling uses. I just refreshed my OpenJDK 7 update source and it looks like the bug is fixed in there. It's fixed in IcedTea as well. There could be the JavaScript issue here as well I can't actually remember, but I thought I had some successful builds with custom JDK's I compiled.
> I did just try with IcedTea 7 and got some other errors. I'm building the latest upstream of OpenJDK 7 now and we'll see if it works. I'll let you know either way.
> Let me know if you have any more questions on this. I did dig into a while ago a little.
> {quote}
--
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
13 years, 3 months
[JBoss JIRA] (AS7-6724) method-params containing an array not correctly processed for EJB2.1 with CMT
by Robert Panzer (JIRA)
[ https://issues.jboss.org/browse/AS7-6724?page=com.atlassian.jira.plugin.s... ]
Robert Panzer updated AS7-6724:
-------------------------------
Attachment: cmt-never-array-params.zip
Maven project containing Arquillian test showing the problem.
> method-params containing an array not correctly processed for EJB2.1 with CMT
> -----------------------------------------------------------------------------
>
> Key: AS7-6724
> URL: https://issues.jboss.org/browse/AS7-6724
> Project: Application Server 7
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
> Environment: JBoss 7.2.0-Final Prerelease (Commit 4ed76c) and JBoss 7.1.3.Final on Win7/64 JDK 1.7.0_09
> Reporter: Robert Panzer
> Assignee: jaikiran pai
> Attachments: cmt-never-array-params.zip
>
>
> It seems that the method-params for container transactions are not matched correctly if the contain arrays.
> I've got an EJB "First" that calls another EJB "Second". Both have the same interface containing a method void test(String[]);
> If I define the transaction attribute NEVER including method-params for "First" and without params for "Second" the test fails with
> JBAS014163: Transaction present on server in Never call (EJB3 13.6.2.6)
> I define the container transaction like this:
> <container-transaction>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>java.lang.String[]</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>java.lang.String</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>int</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>Second</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> </method>
> <trans-attribute>Never</trans-attribute>
> </container-transaction>
> I will attach a test case that fails at the call to test(String[]) but successfully call test(String) and test(int).
--
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
13 years, 3 months
[JBoss JIRA] (AS7-6724) method-params containing an array not correctly processed for EJB2.1 with CMT
by Robert Panzer (JIRA)
Robert Panzer created AS7-6724:
----------------------------------
Summary: method-params containing an array not correctly processed for EJB2.1 with CMT
Key: AS7-6724
URL: https://issues.jboss.org/browse/AS7-6724
Project: Application Server 7
Issue Type: Feature Request
Components: EJB
Affects Versions: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
Environment: JBoss 7.2.0-Final Prerelease (Commit 4ed76c) and JBoss 7.1.3.Final on Win7/64 JDK 1.7.0_09
Reporter: Robert Panzer
Assignee: jaikiran pai
It seems that the method-params for container transactions are not matched correctly if the contain arrays.
I've got an EJB "First" that calls another EJB "Second". Both have the same interface containing a method void test(String[]);
If I define the transaction attribute NEVER including method-params for "First" and without params for "Second" the test fails with
JBAS014163: Transaction present on server in Never call (EJB3 13.6.2.6)
I define the container transaction like this:
<container-transaction>
<method>
<ejb-name>FirstWithParams</ejb-name>
<method-intf>Local</method-intf>
<method-name>test</method-name>
<method-params>
<method-param>java.lang.String[]</method-param>
</method-params>
</method>
<method>
<ejb-name>FirstWithParams</ejb-name>
<method-intf>Local</method-intf>
<method-name>test</method-name>
<method-params>
<method-param>java.lang.String</method-param>
</method-params>
</method>
<method>
<ejb-name>FirstWithParams</ejb-name>
<method-intf>Local</method-intf>
<method-name>test</method-name>
<method-params>
<method-param>int</method-param>
</method-params>
</method>
<method>
<ejb-name>Second</ejb-name>
<method-intf>Local</method-intf>
<method-name>test</method-name>
</method>
<trans-attribute>Never</trans-attribute>
</container-transaction>
I will attach a test case that fails at the call to test(String[]) but successfully call test(String) and test(int).
--
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
13 years, 3 months
[JBoss JIRA] (DROOLS-80) Create a project that will allow Drools to be tested against many OSGi frameworks
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-80?page=com.atlassian.jira.plugin.... ]
Geoffrey De Smet moved JBRULES-3706 to DROOLS-80:
-------------------------------------------------
Project: Drools (was: JBRULES)
Key: DROOLS-80 (was: JBRULES-3706)
Workflow: GIT Pull Request workflow (was: jira)
> Create a project that will allow Drools to be tested against many OSGi frameworks
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-80
> URL: https://issues.jboss.org/browse/DROOLS-80
> Project: Drools
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Cristiano Gavião
> Assignee: Mark Proctor
> Labels: OSGi
>
> The actual project that tests Drools in a OSGi platform was not defined for a reliable and consistent tests on more than one framework.
> So the propose is to create a new project that will use Pax-Exam tool which will able to test Drools bundles in the most important existent frameworks: Equinox, Felix and Knopflerfish.
--
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
13 years, 3 months
[JBoss JIRA] (DROOLS-80) Create a project that will allow Drools to be tested against many OSGi frameworks
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-80?page=com.atlassian.jira.plugin.... ]
Geoffrey De Smet commented on DROOLS-80:
----------------------------------------
We 'll want this code in the git repo droolsjbpm-integration as a submode of drools-osgi (which will be renamed to kie-osgi).
The OSGi related code in droolsjbpm-build-distribution/ will be removed later this week.
> Create a project that will allow Drools to be tested against many OSGi frameworks
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-80
> URL: https://issues.jboss.org/browse/DROOLS-80
> Project: Drools
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Cristiano Gavião
> Assignee: Mark Proctor
> Labels: OSGi
>
> The actual project that tests Drools in a OSGi platform was not defined for a reliable and consistent tests on more than one framework.
> So the propose is to create a new project that will use Pax-Exam tool which will able to test Drools bundles in the most important existent frameworks: Equinox, Felix and Knopflerfish.
--
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
13 years, 3 months
[JBoss JIRA] (JGRP-1594) UNICAST3: introduce connection establishment / teardown
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1594?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1594.
----------------------------
Resolution: Done
> UNICAST3: introduce connection establishment / teardown
> -------------------------------------------------------
>
> Key: JGRP-1594
> URL: https://issues.jboss.org/browse/JGRP-1594
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> [Use case: UNICAST_ConnectionTests.testBClosingUnilaterally()]
> There can be issues when simply sending messages with a conn-id, and the peer closing the connection, e.g.:
> * A and B have connections (send,receive) to each other
> * A sends 10 messages to B on conn-id=1
> * B accepts the 10 messages and passes them up
> * B closes its connection (but hasn't sent ack(10) yet)
> ** Closing the connection, B removes the receive table for A
> * A hasn't received an ACK so it resends the 10 messages with conn-id=1
> * B creates a new connection for A and a new (empty) receive table
> ** B now accepts the 10 *retransmitted* messages from A and delivers them
> B therefore delivers the 10 messages *twice* !
> SOLUTION #1:
> * When closing a connection, don't *remove* it immediately, but only mark is as closed and keep it around for a few minutes
> * A reaper then removes connections that have been marked as closed and have been idle for a few minutes
> ** If messages are received for a closed connection on the same conn-id, remove the closed mark and treat the connection as open again
> *** If A resent the 10 messages, B would still have the receive window, and know that it already received the 10 messages from A and discard them, preventing duplicate delivery
> SOLUTION #2:
> * Introduce explicit connection establishment and teardown, similar to TCP
> * When creating a connection to B, run a simplified SYN-ACK protocol, whereby both parties establish their sending and receiving conn-ids (perhaps also seqnos)
> * When closing a connection, run a simplified FIN-ACK protocol
> ** This would prevent A from resendin the 10 messages, as the send table would have been removed
> * Connection creation and teardown should be time bounded, ie. if a connection cann be created to a peer after some attempts and timeout, throw an exception, which propagates back to the caller, If a connection cannot be closed (e.g. no ACK is received for the FIN), simply close it unilaterally
--
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
13 years, 3 months
[JBoss JIRA] (AS7-5641) Setting transaction timeout on UserTransaction leaks to the thread and doesn't get cleared
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5641?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-5641:
----------------------------------------------
David M. Lloyd <david.lloyd(a)redhat.com> made a comment on [bug 900984|https://bugzilla.redhat.com/show_bug.cgi?id=900984]
>From the forum thread from jhaliday:
"Per the spec the timeout is NOT scoped to the transaction, it's scoped to the Thread. If you want to reset it, you explicitly call setTransactionTimeout(0). Arguably in a Thread pooled environment it's the job of the pooling logic to do that, to give the user the impression they have a new Thread even when it's actually recycled. But that's for the EJB container to address, not the transaction manager. The TM is not aware of the thread pooling and has no opportunity to do such a reset. This is not a TM bug."
So.. this is not a bug. How do I reject a BZ?
> Setting transaction timeout on UserTransaction leaks to the thread and doesn't get cleared
> ------------------------------------------------------------------------------------------
>
> Key: AS7-5641
> URL: https://issues.jboss.org/browse/AS7-5641
> Project: Application Server 7
> Issue Type: Bug
> Components: EE, Transactions
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: jaikiran pai
> Assignee: David Lloyd
>
> A user has reported (with an example) that setting a transaction timeout on the UserTransaction will leak the timeout onto the thread and subsequent transaction creation on that thread uses the leaked value instead of new values.
> More details in the referenced forum thread.
--
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
13 years, 3 months
[JBoss JIRA] (AS7-5178) All classes that implement AsyncListener are treated as components causing JBAS011006
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5178?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated AS7-5178:
-----------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=900711
> All classes that implement AsyncListener are treated as components causing JBAS011006
> -------------------------------------------------------------------------------------
>
> Key: AS7-5178
> URL: https://issues.jboss.org/browse/AS7-5178
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.2.Final (EAP)
> Environment: JBoss EAP 6.0 GA, web services subsystem removed, war deployed containing Metro or CXF web services implementation
> Reporter: Brad Maxwell
> Assignee: Remy Maucherat
>
> It tries to create this class if CXF is packaged in the war: org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation
> And this stack is logged as a warning:
> 11:08:40,879 INFO [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.test.war:main" from Service Module Loader
> 11:08:40,905 WARN [org.jboss.as.ee] (MSC service thread 1-6) JBAS011006: Not installing optional component org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation
> at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> If Metro is packaged in the war, it tries to load com.sun.xml.ws.transport.http.servlet.WSAsyncListener and logs a warning with this stack:
> 16:48:57,302 WARN [org.jboss.as.ee] (MSC service thread 1-1) JBAS011006: Not installing optional component com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1 due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1
> at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
--
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
13 years, 3 months