[JBoss JIRA] Created: (JBAS-8805) Wrong JNDI name for Datasource declared in application.xml
by Juergen Zimmermann (JIRA)
Wrong JNDI name for Datasource declared in application.xml
----------------------------------------------------------
Key: JBAS-8805
URL: https://issues.jboss.org/browse/JBAS-8805
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Final
Reporter: Juergen Zimmermann
I declare a datasource in the EAR's META-INF/application.xml:
<data-source>
<name>java:app/myDS</name>
In the JMX console I only can see java:internal/myEAR/myEAR/myDS.
Also in the EJB's META-INF/persistence.xml I cannot use java:app/myDS, but only java:internal/myEAR/myEAR/myDS.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Issue Comment Edited: (JBAS-8804) Clustering numberguess example doesn't work
by Ales Justin (JIRA)
[ https://issues.jboss.org/browse/JBAS-8804?page=com.atlassian.jira.plugin.... ]
Ales Justin edited comment on JBAS-8804 at 1/14/11 6:29 PM:
------------------------------------------------------------
Proposed patch - trims out jboss.server.home.url.
was (Author: alesj):
Proposed patch.
> Clustering numberguess example doesn't work
> -------------------------------------------
>
> Key: JBAS-8804
> URL: https://issues.jboss.org/browse/JBAS-8804
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Weld/CDI
> Affects Versions: 6.0.0.Final
> Environment: JBoss 6.0.0.Final
> Reporter: Ondrej Skutka
> Assignee: Ales Justin
> Attachments: JBAS-8804.patch
>
>
> - Created cluster according to the readme
> - Ran "mvn -Pjboss6cluster,ftest-jboss-cluster-6"
> - The test failed:
> FAILED: guessingWithFailoverTest
> java.lang.AssertionError: Page should contain message Higher! expected:<true> but was:<false>
> at org.jboss.weld.examples.numberguess.clustertest.selenium.NumberGuessClusteringTest.guessingWithFailoverTest(NumberGuessClusteringTest.java:123)
> at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:74)
> at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:92)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> And indeed, when running manually and shutting down one of the nodes in cluster, it failes to synchronize the session:
> 13:39:03,909 WARN [org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager] Problem accessing session [3V****vgLw__]: org.jboss.weld.exceptions.IllegalStateException: WELD-000612 Unable to deserialize field. Declaring bean id org.jboss.weld.bean-jboss.classloader:id="vfs:///home/ony/Programming/jboss-6.0.0.Final/server/all/farm/weld-numberguess.war"-ManagedBean-class org.jboss.weld.examples.numberguess.Game, declaring class public@SessionScoped @Named class org.jboss.weld.examples.numberguess.Game, field name randomNumber
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Updated: (JBAS-8804) Clustering numberguess example doesn't work
by Ales Justin (JIRA)
[ https://issues.jboss.org/browse/JBAS-8804?page=com.atlassian.jira.plugin.... ]
Ales Justin updated JBAS-8804:
------------------------------
Attachment: JBAS-8804.patch
Proposed patch.
> Clustering numberguess example doesn't work
> -------------------------------------------
>
> Key: JBAS-8804
> URL: https://issues.jboss.org/browse/JBAS-8804
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Weld/CDI
> Affects Versions: 6.0.0.Final
> Environment: JBoss 6.0.0.Final
> Reporter: Ondrej Skutka
> Assignee: Ales Justin
> Attachments: JBAS-8804.patch
>
>
> - Created cluster according to the readme
> - Ran "mvn -Pjboss6cluster,ftest-jboss-cluster-6"
> - The test failed:
> FAILED: guessingWithFailoverTest
> java.lang.AssertionError: Page should contain message Higher! expected:<true> but was:<false>
> at org.jboss.weld.examples.numberguess.clustertest.selenium.NumberGuessClusteringTest.guessingWithFailoverTest(NumberGuessClusteringTest.java:123)
> at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:74)
> at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:92)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> And indeed, when running manually and shutting down one of the nodes in cluster, it failes to synchronize the session:
> 13:39:03,909 WARN [org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager] Problem accessing session [3V****vgLw__]: org.jboss.weld.exceptions.IllegalStateException: WELD-000612 Unable to deserialize field. Declaring bean id org.jboss.weld.bean-jboss.classloader:id="vfs:///home/ony/Programming/jboss-6.0.0.Final/server/all/farm/weld-numberguess.war"-ManagedBean-class org.jboss.weld.examples.numberguess.Game, declaring class public@SessionScoped @Named class org.jboss.weld.examples.numberguess.Game, field name randomNumber
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Assigned: (JBAS-8804) Clustering numberguess example doesn't work
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/JBAS-8804?page=com.atlassian.jira.plugin.... ]
Pete Muir reassigned JBAS-8804:
-------------------------------
Assignee: Ales Justin
> Clustering numberguess example doesn't work
> -------------------------------------------
>
> Key: JBAS-8804
> URL: https://issues.jboss.org/browse/JBAS-8804
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Weld/CDI
> Affects Versions: 6.0.0.Final
> Environment: JBoss 6.0.0.Final
> Reporter: Ondrej Skutka
> Assignee: Ales Justin
>
> - Created cluster according to the readme
> - Ran "mvn -Pjboss6cluster,ftest-jboss-cluster-6"
> - The test failed:
> FAILED: guessingWithFailoverTest
> java.lang.AssertionError: Page should contain message Higher! expected:<true> but was:<false>
> at org.jboss.weld.examples.numberguess.clustertest.selenium.NumberGuessClusteringTest.guessingWithFailoverTest(NumberGuessClusteringTest.java:123)
> at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:74)
> at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:92)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> And indeed, when running manually and shutting down one of the nodes in cluster, it failes to synchronize the session:
> 13:39:03,909 WARN [org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager] Problem accessing session [3V****vgLw__]: org.jboss.weld.exceptions.IllegalStateException: WELD-000612 Unable to deserialize field. Declaring bean id org.jboss.weld.bean-jboss.classloader:id="vfs:///home/ony/Programming/jboss-6.0.0.Final/server/all/farm/weld-numberguess.war"-ManagedBean-class org.jboss.weld.examples.numberguess.Game, declaring class public@SessionScoped @Named class org.jboss.weld.examples.numberguess.Game, field name randomNumber
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Moved: (JBAS-8804) Clustering numberguess example doesn't work
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/JBAS-8804?page=com.atlassian.jira.plugin.... ]
Pete Muir moved WELD-828 to JBAS-8804:
--------------------------------------
Project: JBoss Application Server (was: Weld)
Key: JBAS-8804 (was: WELD-828)
Affects Version/s: 6.0.0.Final
(was: 1.1.0.Final)
Component/s: Weld/CDI
(was: Examples)
(was: Clustering)
Security: Public
> Clustering numberguess example doesn't work
> -------------------------------------------
>
> Key: JBAS-8804
> URL: https://issues.jboss.org/browse/JBAS-8804
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Weld/CDI
> Affects Versions: 6.0.0.Final
> Environment: JBoss 6.0.0.Final
> Reporter: Ondrej Skutka
>
> - Created cluster according to the readme
> - Ran "mvn -Pjboss6cluster,ftest-jboss-cluster-6"
> - The test failed:
> FAILED: guessingWithFailoverTest
> java.lang.AssertionError: Page should contain message Higher! expected:<true> but was:<false>
> at org.jboss.weld.examples.numberguess.clustertest.selenium.NumberGuessClusteringTest.guessingWithFailoverTest(NumberGuessClusteringTest.java:123)
> at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:74)
> at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:92)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> And indeed, when running manually and shutting down one of the nodes in cluster, it failes to synchronize the session:
> 13:39:03,909 WARN [org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager] Problem accessing session [3V****vgLw__]: org.jboss.weld.exceptions.IllegalStateException: WELD-000612 Unable to deserialize field. Declaring bean id org.jboss.weld.bean-jboss.classloader:id="vfs:///home/ony/Programming/jboss-6.0.0.Final/server/all/farm/weld-numberguess.war"-ManagedBean-class org.jboss.weld.examples.numberguess.Game, declaring class public@SessionScoped @Named class org.jboss.weld.examples.numberguess.Game, field name randomNumber
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Updated: (JGRP-1271) MuxMessageDispatcher mutates RequestOptions leading ultimately to potential StackOverflowError
by Eric Sirianni (JIRA)
[ https://issues.jboss.org/browse/JGRP-1271?page=com.atlassian.jira.plugin.... ]
Eric Sirianni updated JGRP-1271:
--------------------------------
Description:
The presence of 'public static final' RequestOptions SYNC and ASYNC implies strongly that RequestOptions are immutable. Otherwise, clients could be changing the meaning of these shared constants.
However, MuxMessageDispatcher.cast() mutates the passed-in RequestOptions to set the RspFilter. It chains the existing RspFilter in the RequestOptions to a new one:
options.setRspFilter((filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter())
The result of this is that the following innocent looking code code will quickly lead to a stack overflow as the RspFilter chain in the RequestOptions.ASYNC object grows without bound:
while (true) {
muxMessageDispatcher.cast(dests, msg, RequestOptions.ASYNC, false);
}
The workaround is to create a new RequestOptions object per call to cast() :
while (true) {
muxMessageDispatcher.cast(dests, msg, new RequestOptions(...), false);
}
I recommend either:
A. Deprecating the public static final RequestOptions ASYNC and SYNC fields and heavily JavaDoc'ing that clients must use a fresh RequestOptions for each send() or cast() invocation.
-or-
B. JavaDoc'ing the RequestOptions class as *immutable* and fixing MuxMessageDispatcher and other such JGroups blocks that mutate RequestOptions. You may wish to add a "copy constructor" to RequestOptions to facilitate this. The fix for MuxMessageDispatcher is fairly easy - just "clone" the passed-in RequestOptions and set the NoMuxHandlerRspFilter on the new RequestOptions object:
< return super.cast(dests, msg, options.setRspFilter((filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter()), blockForResults);
---
> RequestOptions newOptions = new RequestOptions(options.getMode(), options.getTimeout(), options.getAnycasting(), options, (filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter(), options.getFlags());
> return super.cast(dests, msg, newOptions, blockForResults);
was:
The presence of 'public static final' RequestOptions SYNC and ASYNC implies strongly that RequestOptions are immutable. Otherwise, clients could be changing the meaning of these shared constants.
However, MuxMessageDispatcher.cast() mutates the passed-in RequestOptions to set the RspFilter. It chains the existing RspFilter in the RequestOptions to a new one:
options.setRspFilter((filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter())
The result of this is that the following innocent looking code code will quickly lead to a stack overflow as the RspFilter chain in the RequestOptions.ASYNC object grows without bound:
while (true) {
muxMessageDispatcher.cast(dests, msg, RequestOptions.ASYNC, false);
}
The workaround is to create a new RequestOptions object per call to cast() :
while (true) {
muxMessageDispatcher.cast(dests, msg, new RequestOptions(...), false);
}
I recommend either:
A. Deprecating the public static final RequestOptions ASYNC and SYNC fields and heavily JavaDoc'ing that clients must use a fresh RequestOptions for each send() or cast() invocation.
-or-
B. JavaDoc'ing the RequestOptions class as *immutable* and fixing MuxMessageDispatcher and other such JGroups blocks that mutate RequestOptions. You may wish to add a "copy constructor" to RequestOptions to facilitate this. The fix for MuxMessageDispatcher is fairly easy - just "clone" the passed-in RequestOptions and set the NoMuxHandlerRspFilter on the new RequestOptions object:
< return super.cast(dests, msg, options.setRspFilter((filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter()), blockForResults);
---
> RequestOptions newOptions = new RequestOptions(options.getMode(), options.getTimeout(), options.getAnycasting(), options, (filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter(), options.getFlags());
> return super.cast(dests, msg, newOptions), blockForResults);
> MuxMessageDispatcher mutates RequestOptions leading ultimately to potential StackOverflowError
> ----------------------------------------------------------------------------------------------
>
> Key: JGRP-1271
> URL: https://issues.jboss.org/browse/JGRP-1271
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.11
> Environment: All
> Reporter: Eric Sirianni
> Assignee: Bela Ban
>
> The presence of 'public static final' RequestOptions SYNC and ASYNC implies strongly that RequestOptions are immutable. Otherwise, clients could be changing the meaning of these shared constants.
> However, MuxMessageDispatcher.cast() mutates the passed-in RequestOptions to set the RspFilter. It chains the existing RspFilter in the RequestOptions to a new one:
> options.setRspFilter((filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter())
> The result of this is that the following innocent looking code code will quickly lead to a stack overflow as the RspFilter chain in the RequestOptions.ASYNC object grows without bound:
> while (true) {
> muxMessageDispatcher.cast(dests, msg, RequestOptions.ASYNC, false);
> }
> The workaround is to create a new RequestOptions object per call to cast() :
> while (true) {
> muxMessageDispatcher.cast(dests, msg, new RequestOptions(...), false);
> }
> I recommend either:
> A. Deprecating the public static final RequestOptions ASYNC and SYNC fields and heavily JavaDoc'ing that clients must use a fresh RequestOptions for each send() or cast() invocation.
> -or-
> B. JavaDoc'ing the RequestOptions class as *immutable* and fixing MuxMessageDispatcher and other such JGroups blocks that mutate RequestOptions. You may wish to add a "copy constructor" to RequestOptions to facilitate this. The fix for MuxMessageDispatcher is fairly easy - just "clone" the passed-in RequestOptions and set the NoMuxHandlerRspFilter on the new RequestOptions object:
> < return super.cast(dests, msg, options.setRspFilter((filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter()), blockForResults);
> ---
> > RequestOptions newOptions = new RequestOptions(options.getMode(), options.getTimeout(), options.getAnycasting(), options, (filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter(), options.getFlags());
> > return super.cast(dests, msg, newOptions, blockForResults);
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (SECURITY-56) SecurityContextAssociation missing in client path
by Thomas Diesler (JIRA)
SecurityContextAssociation missing in client path
-------------------------------------------------
Key: SECURITY-56
URL: http://jira.jboss.com/jira/browse/SECURITY-56
Project: JBoss Security and Identity Management
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Assigned To: Anil Saldhana
bin/twiddle.sh doe not work in AS5.0 because of missing security classes.
A scan on client jars shows that SecurityContextAssociation is not part of any client jar
[tdiesler@jbws jboss-5.0.0.Beta3]$ bin/twiddle.sh -s jnp://jbws2:1099 get jboss.system:type=Server Started
Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/security/plugins/SecurityContextAssociation
at org.jboss.proxy.SecurityActions$1.getPrincipal(SecurityActions.java:57)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:58)
at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
at $Proxy0.getAttributes(Unknown Source)
at org.jboss.console.twiddle.command.GetCommand.execute(GetCommand.java:168)
at org.jboss.console.twiddle.Twiddle.main(Twiddle.java:305)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months