[JBoss JIRA] (JBRULES-3693) Pull Request to update smooks to 1.5.1
by George Varsamis (JIRA)
George Varsamis created JBRULES-3693:
----------------------------------------
Summary: Pull Request to update smooks to 1.5.1
Key: JBRULES-3693
URL: https://issues.jboss.org/browse/JBRULES-3693
Project: Drools
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Alpha1
Reporter: George Varsamis
Assignee: Mark Proctor
Switchyard requires Smooks v 1.5.1 . I have updated drools parent to use smooks 1.5.1 and also updated the source code in droolsjbpm-integration/drools-pipeline to reflect this. The change is trivial. I have run the tests and the change had no adverse effect on the codebase.
I will attach the pull requests to this ticket.
--
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, 5 months
[JBoss JIRA] (JGRP-1410) globalThreadGroup not destroyed creates a classloader memory leak
by Jean-Philippe Gariepy (Created) (JIRA)
globalThreadGroup not destroyed creates a classloader memory leak
-----------------------------------------------------------------
Key: JGRP-1410
URL: https://issues.jboss.org/browse/JGRP-1410
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.1
Environment: linux w/ java 1.6
Reporter: Jean-Philippe Gariepy
Assignee: Bela Ban
When all channels are closed, the globalThreadGroup is not destroyed. For a normal (i.e. non-web) application, this is not a problem since the process will exit anyway. However, for a Java Enterprise web application, this causes a classloader memory leak since the ThreadGroup object has strong references to JGroups instances having strong references to their class object having strong reference to their class loader. Since the class loader is pointed by strong references, the it cannot be garbage collected and hence a leak is created each time the web application is stopped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-5974) Persistent @Schedule timers are not removed if the persistent attribute change
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created AS7-5974:
-------------------------------------
Summary: Persistent @Schedule timers are not removed if the persistent attribute change
Key: AS7-5974
URL: https://issues.jboss.org/browse/AS7-5974
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.2.0.Alpha1
Reporter: Wolf-Dieter Fink
Assignee: jaikiran pai
If a EJB (Stateless) is deployed with a @Schedule annotation which is persistent the timer will not be removed if it is redeployed and the only change is the persistent flag.
If the time schedule is changed in the same deploment the timer will be removed from the store.
There is no difference for managed or unmanaged deployments.
--
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, 5 months
[JBoss JIRA] (AS7-5655) Cannot restart ejb3 bundle after activation failure
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-5655:
-----------------------------------
Summary: Cannot restart ejb3 bundle after activation failure
Key: AS7-5655
URL: https://issues.jboss.org/browse/AS7-5655
Project: Application Server 7
Issue Type: Bug
Components: JPA / Hibernate, OSGi
Reporter: Thomas Diesler
Assignee: Thomas Diesler
{code}
Caused by: java.lang.IllegalStateException: JBAS014666: Duplicate resource persistence-bundle-b.jar#simple-persistence
at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:225)
at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:135)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addManagementConsole(PersistenceUnitServiceHandler.java:727)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnit(PersistenceUnitServiceHandler.java:406)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:274)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleJarDeployment(PersistenceUnitServiceHandler.java:142)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:117)
at org.jboss.as.jpa.processor.PersistenceCompleteInstallProcessor.deploy(PersistenceCompleteInstallProcessor.java:48)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2
{code}
--
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, 5 months
[JBoss JIRA] (JGRP-1540) TP: simplified message bundler
by Bela Ban (JIRA)
Bela Ban created JGRP-1540:
------------------------------
Summary: TP: simplified message bundler
Key: JGRP-1540
URL: https://issues.jboss.org/browse/JGRP-1540
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
Instead of maintaining a hashmap (like for the current bundlers), a simple blocking bounded queue of messages would be used. Whenever we've reached M bytes or N milliseconds have elapsed, a consumer thread processes the queue in the following manner:
- First set the queue to a new queue (volatile assignment), reuse a number of queues
- Iterate through all messages in the current queue, for each message:
- If the destination is the same as the current destination, write the message to the stream for the current destination
- Else set the current destination to msg.getDest() and create an output stream (similar to writing a message list)
- Stream the current message to the output stream
- If there was a previous destination, close the associated output stream and send the message list
Example:
- We have messages with the following destinations: A, null, null, B, B, null, A, null, null, null
- First we send a message list consisting of 1 message to A
- Next we send a message list consisting of 2 messages to the cluster (dest==null)
- Then we send a batch of 2 messages to B, 1 to the cluster, 1 to A and 3 to the cluster
--
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, 5 months
[JBoss JIRA] (AS7-6021) Occuring java.io.NotSerializableException: org.jboss.seam.security.SecurityExtension for file-passivation-store
by Artur Mioduszewski (JIRA)
Artur Mioduszewski created AS7-6021:
---------------------------------------
Summary: Occuring java.io.NotSerializableException: org.jboss.seam.security.SecurityExtension for file-passivation-store
Key: AS7-6021
URL: https://issues.jboss.org/browse/AS7-6021
Project: Application Server 7
Issue Type: Feature Request
Affects Versions: 7.1.1.Final
Environment: JBoss AS 7.1.1.Final ,
deployed EAR - engined by seam 3.1
Reporter: Artur Mioduszewski
For stateful configuration on AS 7.1.1.Final:
{code}
<session-bean>
<stateless>
<bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
</stateless>
<stateful default-access-timeout="5000" cache-ref="passivating"/>
<singleton default-access-timeout="5000"/>
</session-bean>
<mdb>
<resource-adapter-ref resource-adapter-name="hornetq-ra"/>
<bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
</mdb>
<pools>
<bean-instance-pools>
<strict-max-pool name="slsb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
<strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
</bean-instance-pools>
</pools>
<caches>
<cache name="simple" aliases="NoPassivationCache"/>
<cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
</caches>
<passivation-stores>
<file-passivation-store name="file"/>
</passivation-stores>
{code}
following bug occurs:
{code}
01:53:06,659 INFO [org.jboss.as.ejb3.cache.spi.impl.PassivateTask:47]: JBAS014530: Cache entry {[116, 101, 62, -40, 115, 95, 67, -89, -101, 122, 33, -85, 12, -1
21, -16, -18]} is in use: java.lang.IllegalStateException: JBAS014530: Cache entry {[116, 101, 62, -40, 115, 95, 67, -89, -101, 122, 33, -85, 12, -121, -16, -18]
} is in use
at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:177) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.
Final]
at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.F
inal]
at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_05]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_05]
at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_05]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_05]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_05]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_05]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_05]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_05]
01:53:06,659 INFO [org.jboss.as.ejb3.cache.spi.impl.PassivateTask:47]: JBAS014530: Cache entry {[-67, 30, -13, 127, -73, -125, 79, 54, -68, -71, -62, 24, -109,
-10, 51, -96]} is in use: java.lang.IllegalStateException: JBAS014530: Cache entry {[-67, 30, -13, 127, -73, -125, 79, 54, -68, -71, -62, 24, -109, -10, 51, -96]
} is in use
at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:177) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.
Final]
at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.F
inal]
at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_05]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_05]
at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_05]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_05]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_05]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_05]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_05]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_05]
01:53:06,812 INFO [org.jboss.as.ejb3.cache.spi.impl.PassivateTask:47]: JBAS014538: Failed to passivate c689b1b7-6d69-4f49-98c7-47b124e832cf: java.lang.RuntimeEx
ception: JBAS014538: Failed to passivate c689b1b7-6d69-4f49-98c7-47b124e832cf
at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:248) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.ejb3.cache.impl.backing.SimpleBackingCacheEntryStore.passivate(SimpleBackingCacheEntryStore.java:155) [jboss-as-ejb3-7.1.1.Final.jar:7.1.
1.Final]
at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.
Final]
at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.F
inal]
at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.prePassivate(SerializationGroupMemberContainer.java:174) [jboss-as-ejb3-7.1.1.F
inal.jar:7.1.1.Final]
at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.prePassivate(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.1.Fi
nal.jar:7.1.1.Final]
at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:184) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.
Final]
at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.F
inal]
at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_05]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_05]
at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_05]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_05]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_05]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_05]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_05]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_05]
Caused by: java.io.NotSerializableException: org.jboss.seam.security.SecurityExtension
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:585)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
at org.jboss.marshalling.river.RiverObjectOutputStream.defaultWriteObject(RiverObjectOutputStream.java:159)
at java.util.Collections$SynchronizedCollection.writeObject(Collections.java:1659) [rt.jar:1.7.0_05]
at sun.reflect.GeneratedMethodAccessor648.invoke(Unknown Source) [:1.7.0_05]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_05]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_05]
at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:680)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:69)
at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:60)
at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:54)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:342) [rt.jar:1.7.0_05]
at java.util.concurrent.ConcurrentHashMap.writeObject(ConcurrentHashMap.java:1454) [rt.jar:1.7.0_05]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_05]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_05]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_05]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_05]
at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
at org.jboss.marshalling.river.RiverObjectOutputStream.defaultWriteObject(RiverObjectOutputStream.java:159)
at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupImpl.writeObject(SerializationGroupImpl.java:347) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_05]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_05]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_05]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_05]
at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:239) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
... 17 more
Caused by: an exception which occurred:
in field extension
in field instance
in field c
in field parentDependentInstances
in field creationalContext
in field serializableInterceptors
in field memberObjects
in object org.jboss.as.ejb3.cache.impl.backing.SerializationGroupImpl@17cf8b80
{code}
--
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, 5 months
[JBoss JIRA] (AS7-3160) Could not find Extension-List entry ExtensionListEntry because of Java 6+ Extension Mecanism
by Cristhian Lopez (Created) (JIRA)
Could not find Extension-List entry ExtensionListEntry because of Java 6+ Extension Mecanism
--------------------------------------------------------------------------------------------
Key: AS7-3160
URL: https://issues.jboss.org/browse/AS7-3160
Project: Application Server 7
Issue Type: Bug
Components: Class Loading
Affects Versions: 7.1.0.Final
Environment: JDK 1.6.0_30 b12
JBoss AS 7.1 CR1b
Reporter: Cristhian Lopez
Assignee: David Lloyd
When deploying Liferay 6.1 I'm getting the following error
{code}08:08:38,561 WARN [org.jboss.as.server.deployment.module.module-extension-list-processor] (MSC service thread 1-1) Could not find Extension-List entry ExtensionListEntry [name=javax.crypto, title=crypto] referenced from ResourceRoot [root="/D:/Development/Servers/jboss-as-7.1.0.CR1b/content/ROOT.war/WEB-INF/classes"]{code}
After some debug on the JBoss 7.1 CR1b source I found that it uses the java.ext.dirs property to find the ext libs, but since java 1.6 the property returns a classpath formated string with more than one path where the extensions are located(http://docs.oracle.com/javase/tutorial/ext/basics/install.html), but on the JBoss code I found that it's trying to parse the property value as a File path directly.
As you can se on the ServerEnvironment.java line 292
{code}// Java system-wide extension dirs
javaExtDirs = getFilesFromProperty(JAVA_EXT_DIRS, props);{code}
and line 524
{code}
private File getFileFromProperty(final String name, final Properties props) {
String value = props.getProperty(name, null);
if (value != null) {
File f = new File(value);
return f;
}
return null;
}
{code}
This is causing that the server can´t find the extensions and warning about it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months