[JBoss JIRA] (WFLY-1586) java.lang.NoClassDefFoundError: Could not initialize class com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-1586?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf updated WFLY-1586:
--------------------------------
Description:
With the latest update of OpenJDK to 1.7.0.25-2.3.10.3 there is regression w.r.t. WebServices.
Failing tests:
{noformat}
org.jboss.as.test.integration.ws.ejb.ContextHandlerEndpointTestCase
org.jboss.as.test.integration.ws.injection.ejb.basic.EjbEndpointInsideWarTestCase
org.jboss.as.test.integration.ws.injection.ejb.basic.InjectionTestCase
org.jboss.as.test.integration.ws.wsa.TestNoAddressingTestCase
org.jboss.as.test.integration.ws.wsa.TestOptionalAddressingTestCase
org.jboss.as.test.integration.ws.wsa.TestRequiredAddressingTestCase
org.jboss.as.test.integration.ws.wsse.sign.EJBSignTestCase
org.jboss.as.test.integration.ws.wsse.signencrypt.EJBSignEncryptMultipleClientsTestCase
org.jboss.as.test.integration.ws.wsse.signencrypt.EJBSignEncryptTestCase
org.jboss.as.test.integration.ws.wsse.signencrypt.SignEncryptMultipleClientsTestCase
org.jboss.as.test.integration.ws.wsse.signencrypt.SignEncryptTestCase
org.jboss.as.test.integration.ws.wsse.sign.SignTestCase
org.jboss.as.test.xts.simple.wsat.client.WSATTestCase
org.jboss.as.test.xts.simple.wsba.coordinatorcompletion.client.WSBACoordinatorCompletionTestCase
org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase
{noformat}
was:With the latest update of OpenJDK to 1.7.0.25-2.3.10.3 there is regression w.r.t. WebServices.
> java.lang.NoClassDefFoundError: Could not initialize class com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1586
> URL: https://issues.jboss.org/browse/WFLY-1586
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.0.0.Alpha2
> Environment: java version "1.7.0_25"
> OpenJDK Runtime Environment (fedora-2.3.10.3.fc17-x86_64)
> OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
> java-1.7.0-openjdk-1.7.0.25-2.3.10.3.fc17.x86_64
> Reporter: Carlo de Wolf
> Assignee: Alessio Soldano
> Priority: Blocker
> Attachments: org.jboss.as.test.xts.simple.wsat.client.WSATTestCase.txt
>
>
> With the latest update of OpenJDK to 1.7.0.25-2.3.10.3 there is regression w.r.t. WebServices.
> Failing tests:
> {noformat}
> org.jboss.as.test.integration.ws.ejb.ContextHandlerEndpointTestCase
> org.jboss.as.test.integration.ws.injection.ejb.basic.EjbEndpointInsideWarTestCase
> org.jboss.as.test.integration.ws.injection.ejb.basic.InjectionTestCase
> org.jboss.as.test.integration.ws.wsa.TestNoAddressingTestCase
> org.jboss.as.test.integration.ws.wsa.TestOptionalAddressingTestCase
> org.jboss.as.test.integration.ws.wsa.TestRequiredAddressingTestCase
> org.jboss.as.test.integration.ws.wsse.sign.EJBSignTestCase
> org.jboss.as.test.integration.ws.wsse.signencrypt.EJBSignEncryptMultipleClientsTestCase
> org.jboss.as.test.integration.ws.wsse.signencrypt.EJBSignEncryptTestCase
> org.jboss.as.test.integration.ws.wsse.signencrypt.SignEncryptMultipleClientsTestCase
> org.jboss.as.test.integration.ws.wsse.signencrypt.SignEncryptTestCase
> org.jboss.as.test.integration.ws.wsse.sign.SignTestCase
> org.jboss.as.test.xts.simple.wsat.client.WSATTestCase
> org.jboss.as.test.xts.simple.wsba.coordinatorcompletion.client.WSBACoordinatorCompletionTestCase
> org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase
> {noformat}
--
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
[JBoss JIRA] (WFLY-248) Loopback addresses in the range 127.0.0.2 - 127.255.255.255 should be supported
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-248?page=com.atlassian.jira.plugin.s... ]
Rostislav Svoboda reassigned WFLY-248:
--------------------------------------
Assignee: Rostislav Svoboda
> Loopback addresses in the range 127.0.0.2 - 127.255.255.255 should be supported
> -------------------------------------------------------------------------------
>
> Key: WFLY-248
> URL: https://issues.jboss.org/browse/WFLY-248
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Environment: Linux Fedora 13
> Reporter: Bela Ban
> Assignee: Rostislav Svoboda
> Fix For: 8.0.0.Beta1
>
>
> When starting JBoss like this: "standalone.sh -b 127.0.0.2 -c standalone-ha.xml", the startup fails because 127.0.0.2 cannot be resolved.
> However, a loopback address should be recognized even if it doesn't resolve to an interface. The code below works for example:
> {code}
> InetAddress addr=InetAddress.getByName("127.0.0.5");
> boolean is_loopback=addr.isLoopback(); // should be true
> {code}
> Loopback addresses are very useful for local testing, ie. starting of multiple JBoss instances on the same box.
--
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
[JBoss JIRA] (JBVFS-188) TimedCachePolicy using unsynchronized Map by default
by Keiichi Sato (JIRA)
[ https://issues.jboss.org/browse/JBVFS-188?page=com.atlassian.jira.plugin.... ]
Keiichi Sato updated JBVFS-188:
-------------------------------
Description:
TimedCachePolicy should be created with synchronized Map by default. If TimedCachePolicy is created unsynchronized Map, ConcurrentModificationException occurs on TimedCachePolicy.getValidKeys() method.
{noformat}
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810)
at java.util.HashMap$EntryIterator.next(HashMap.java:851)
at java.util.HashMap$EntryIterator.next(HashMap.java:849)
at org.jboss.util.TimedCachePolicy.getValidKeys(TimedCachePolicy.java:364)
at org.jboss.virtual.plugins.cache.IterableTimedVFSCache.findContext(IterableTimedVFSCache.java:65)
at org.jboss.virtual.plugins.cache.CombinedVFSCache.findContext(CombinedVFSCache.java:116)
at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:148)
at org.jboss.virtual.VFS.getRoot(VFS.java:243)
at org.jboss.virtual.VFS.getRoot(VFS.java:313)
{noformat}
When JBoss starts with the default configuration, the following output in boot.log.
{noformat}
21:19:20,173 DEBUG [IterableTimedVFSCache] Creating timed cache policy, lifetime: null, threadSafe: true, resolution: null
{noformat}
This does not mean TimedCachePolicy is threadSafe
{code:title=http://anonsvn.jboss.org/repos/jbossas/projects/vfs/tags/2.2.0.SP1/src/main/java/org/jboss/virtual/plugins/cache/TimedVFSCache.java|borderStyle=solid}
protected TimedCachePolicy createCachePolicy()
-- snip --
log.debug("Creating timed cache policy, lifetime: " + defaultLifetime + ", threadSafe: " + threadSafe + ", resolution: " + resolution);
TimedCachePolicy tcp;
if (defaultLifetime == null)
tcp = new TimedCachePolicy();
else if (resolution != null)
tcp = new TimedCachePolicy(defaultLifetime, threadSafe, resolution);
else
tcp = new TimedCachePolicy(defaultLifetime);
-- snip --
{code}
If defaultLifetime and resolution are null, TimedCachePolicy is created using the default constructor. The default constructor is as the following.
{code:title=http://anonsvn.jboss.org/repos/common/common-core/tags/2.2.18.GA/src/main/java/org/jboss/util/TimedCachePolicy.java|borderStyle=solid}
public TimedCachePolicy()
{
this(30*60, false, 0);
}
{code}
The default constructor specifies threadSafe to false.
was:
TimedCachePolicy should be created with synchronized Map by default. If TimedCachePolicy is created unsynchronized Map, ConcurrentModificationException occurs on TimedCachePolicy.getValidKeys() method.
{noformat}
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810)
at java.util.HashMap$EntryIterator.next(HashMap.java:851)
at java.util.HashMap$EntryIterator.next(HashMap.java:849)
at org.jboss.util.TimedCachePolicy.getValidKeys(TimedCachePolicy.java:364)
at org.jboss.virtual.plugins.cache.IterableTimedVFSCache.findContext(IterableTimedVFSCache.java:65)
at org.jboss.virtual.plugins.cache.CombinedVFSCache.findContext(CombinedVFSCache.java:116)
at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:148)
at org.jboss.virtual.VFS.getRoot(VFS.java:243)
at org.jboss.virtual.VFS.getRoot(VFS.java:313)
{noformat}
When JBoss starts with the default configuration, the following output in boot.log.
{noformat}
21:19:20,173 DEBUG [IterableTimedVFSCache] Creating timed cache policy, lifetime: null, threadSafe: true, resolution: null
{noformat}
This does not mean TimedCachePolicy is threadSafe
{code:title=http://anonsvn.jboss.org/repos/jbossas/projects/vfs/tags/2.2.0.SP1/src/main/java/org/jboss/virtual/plugins/cache/TimedVFSCache.java|borderStyle=solid}
protected TimedCachePolicy createCachePolicy()
-- snip --
log.debug("Creating timed cache policy, lifetime: " + defaultLifetime + ", threadSafe: " + threadSafe + ", resolution: " + resolution);
TimedCachePolicy tcp;
if (defaultLifetime == null)
tcp = new TimedCachePolicy();
else if (resolution != null)
tcp = new TimedCachePolicy(defaultLifetime, threadSafe, resolution);
else
tcp = new TimedCachePolicy(defaultLifetime);
-- snip --
{code}
If defaultLifetime and resolution are null, TimedCachePolicy is created the default constructor. The default constructor is as the following.
{code:title=http://anonsvn.jboss.org/repos/common/common-core/tags/2.2.18.GA/src/main/java/org/jboss/util/TimedCachePolicy.java|borderStyle=solid}
public TimedCachePolicy()
{
this(30*60, false, 0);
}
{code}
The default constructor specifies threadsafe to false.
> TimedCachePolicy using unsynchronized Map by default
> ----------------------------------------------------
>
> Key: JBVFS-188
> URL: https://issues.jboss.org/browse/JBVFS-188
> Project: JBoss VFS
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Release
> Affects Versions: 2.2.0.SP1
> Reporter: Keiichi Sato
> Assignee: David Lloyd
>
> TimedCachePolicy should be created with synchronized Map by default. If TimedCachePolicy is created unsynchronized Map, ConcurrentModificationException occurs on TimedCachePolicy.getValidKeys() method.
> {noformat}
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810)
> at java.util.HashMap$EntryIterator.next(HashMap.java:851)
> at java.util.HashMap$EntryIterator.next(HashMap.java:849)
> at org.jboss.util.TimedCachePolicy.getValidKeys(TimedCachePolicy.java:364)
> at org.jboss.virtual.plugins.cache.IterableTimedVFSCache.findContext(IterableTimedVFSCache.java:65)
> at org.jboss.virtual.plugins.cache.CombinedVFSCache.findContext(CombinedVFSCache.java:116)
> at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:148)
> at org.jboss.virtual.VFS.getRoot(VFS.java:243)
> at org.jboss.virtual.VFS.getRoot(VFS.java:313)
> {noformat}
> When JBoss starts with the default configuration, the following output in boot.log.
> {noformat}
> 21:19:20,173 DEBUG [IterableTimedVFSCache] Creating timed cache policy, lifetime: null, threadSafe: true, resolution: null
> {noformat}
> This does not mean TimedCachePolicy is threadSafe
> {code:title=http://anonsvn.jboss.org/repos/jbossas/projects/vfs/tags/2.2.0.SP1/src/main/java/org/jboss/virtual/plugins/cache/TimedVFSCache.java|borderStyle=solid}
> protected TimedCachePolicy createCachePolicy()
> -- snip --
> log.debug("Creating timed cache policy, lifetime: " + defaultLifetime + ", threadSafe: " + threadSafe + ", resolution: " + resolution);
> TimedCachePolicy tcp;
> if (defaultLifetime == null)
> tcp = new TimedCachePolicy();
> else if (resolution != null)
> tcp = new TimedCachePolicy(defaultLifetime, threadSafe, resolution);
> else
> tcp = new TimedCachePolicy(defaultLifetime);
> -- snip --
> {code}
> If defaultLifetime and resolution are null, TimedCachePolicy is created using the default constructor. The default constructor is as the following.
> {code:title=http://anonsvn.jboss.org/repos/common/common-core/tags/2.2.18.GA/src/main/java/org/jboss/util/TimedCachePolicy.java|borderStyle=solid}
> public TimedCachePolicy()
> {
> this(30*60, false, 0);
> }
> {code}
> The default constructor specifies threadSafe to false.
--
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
[JBoss JIRA] (WFLY-221) Batch scripts should show some error message when we set JAVA_HOME to nonexisting folder
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-221?page=com.atlassian.jira.plugin.s... ]
Rostislav Svoboda resolved WFLY-221.
------------------------------------
Fix Version/s: 8.0.0.Alpha3
(was: 8.0.0.CR1)
Resolution: Done
> Batch scripts should show some error message when we set JAVA_HOME to nonexisting folder
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-221
> URL: https://issues.jboss.org/browse/WFLY-221
> Project: WildFly
> Issue Type: Enhancement
> Components: Scripts
> Reporter: Brian Stansberry
> Assignee: Rostislav Svoboda
> Fix For: 8.0.0.Alpha3
>
>
> steps to reproduce:
> ...
> {code}jboss-eap-6.0\bin>set JAVA_HOME=c:\dummy
> jboss-eap-6.0\bin>standalone.bat
> Calling "W:\tmp\pk\jboss-eap-6.0\bin\standalone.conf.bat"
> >{code}
> ...
> batch script will end on this line (standalone.bat)
> l:73 "%JAVA%" -client -version 2>&1 | findstr /I /C:"Client VM" > nul
> On linux we get at least error message:
> ./standalone.sh: line 178: /home/dummy/bin/java: No such file or directory
--
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