[JBoss JIRA] Updated: (JBAS-3198) Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA).
by Adrian Brock (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3198?page=all ]
Adrian Brock updated JBAS-3198:
-------------------------------
Assignee: Tom Elrod (was: Scott M Stark)
> Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA).
> -----------------------------------------------------------------------------------
>
> Key: JBAS-3198
> URL: http://jira.jboss.com/jira/browse/JBAS-3198
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: ClassLoading
> Affects Versions: JBossAS-4.0.3 SP1
> Environment: Windows XP, HP-UX 11, JDK 1.4.2 and 1.5
> Reporter: Eric Hambuch
> Assigned To: Tom Elrod
>
> When using the pooled invoker (PooledInvokerHA) in the "all" configuration with separated classloaders for each EAR (as described in Wiki:ClassLoadingConfiguration) an invocation to a bean causes confusion to the separated classloaders.
> More detailed:
> I switched from jrmpha-invoker (which creates a new thread for each request which is really bad) to pooledha invoker in a clustered environment. I have to Stateless Session Beans that share the same bean interface. Each Session Bean is deployed in a separate EAR. In "ear-deployer.xml" I switched "isolated" to "true" to separate the classloaders of the EARs.
> When I call the first bean everything works fine. But when I try to call the second bean (same interface, but different bean!) JBoss throws the following exception:
> java.rmi.ServerException: RuntimeException; nested exception is:
> java.lang.IllegalArgumentException: argument type mismatch
> at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:386)
> at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:196)
> at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:264)
> at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
> at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
> at org.jboss.ejb.Container.invoke(Container.java:873)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.invocation.pooled.server.PooledInvokerHA.invoke(PooledInvokerHA.java:146)
> at org.jboss.invocation.pooled.server.ServerThread.processInvocation(ServerThread.java:213)
> at org.jboss.invocation.pooled.server.ServerThread.dorun(ServerThread.java:268)
> at org.jboss.invocation.pooled.server.ServerThread.run(ServerThread.java:139)
> Caused by: java.lang.IllegalArgumentException: argument type mismatch
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
> at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
> at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:149)
> at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
> at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:106)
> at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:158)
> at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:62)
> at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:154)
> at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:153)
> at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
> The IllegalArgumentException comes from the fact that the Method.invoke() is called with a class of the wrong classloader (class from other EAR).
> With jrmpha-invoker everything works fine. Maybe the thread pool causes a mixture of the classloaders?
> I created a minimized example that can be provided if required.
--
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
19 years, 8 months
[JBoss JIRA] Created: (JBAS-3849) Duplicating _$$_javassist_ classes after remote - call - OutOfMemory: PermGen
by Piotr Tabor (JIRA)
Duplicating _$$_javassist_ classes after remote - call - OutOfMemory: PermGen
-----------------------------------------------------------------------------
Key: JBAS-3849
URL: http://jira.jboss.com/jira/browse/JBAS-3849
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Remoting
Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA, JBossAS-4.0.4.CR2
Environment:
« Hide
Linux Gentoo 2.6.18, JVM 1.5.0.08, 1.5.0.09, amd64
RedHat Linux EE 4.0. JVM 1.5.0.09, intel
Windows XP, JVM 1.5.0.09, intel
Reporter: Piotr Tabor
Assigned To: Tom Elrod
Priority: Blocker
A simple test (Books/Users) to reproduce the problem.
beantestclient - a simple test client application (runnable: com.newitech.beantest.ejb.Client)
beantest - simple EJB 3 beans.
==========================================================
ANOTHER EXAMPLE AND IDEA OF BUG
PermGen in EJB3 client aplication by remote interface.
The application is as sample as it can be:
-get remote interface of stateless EJB3 (by JNDI)
- ask 1000 times to get a Collection (List) of 10 EntityBeans.
After 255 there is OutOfMemory: PermGen.
JVM options changes nothing (eventualy more PermSpace => longer run).
The reason looks like the Javassist create lazyinitializer classes for every EntityBean retrived from the server.
So: When I debug on server-side, I got before sending Entity to client:
I got:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_7> 13434
...
myEntity[0].user=<UserEntity_$$_javassist_15>...
myEntity[0].stage=<StageEntity_$$_javassist_17>...
And every remote call the class names (name)_$..._javassist_(index) got the same
indexes (7,15,17) on server side (end every entity in returned collections of entities)
But when I debug on client site - after return from remote call - the indexes of
all returned entities are different (Each next increments index).
So after first call I got:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_0>...
...
myEntity[0].user=<UserEntity_$$_javassist_1>...
myEntity[0].stage=<StageEntity_$$_javassist_2>...
...
myEntity[1].id=143534
myEntity[1].flow=<FlowEntity_$$_javassist_3>
...
myEntity[1].user=<UserEntity_$$_javassist_4>...
myEntity[1].stage=<StageEntity_$$_javassist_5>...
...
After secund call:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_6>...
...
myEntity[0].user=<UserEntity_$$_javassist_7>...
myEntity[0].stage=<StageEntity_$$_javassist_8>...
...
myEntity[1].id=143534
myEntity[1].flow=<FlowEntity_$$_javassist_9>
...
myEntity[1].user=<UserEntity_$$_javassist_10>...
myEntity[1].stage=<StageEntity_$$_javassist_11>...
...
And so on... ... and permGen after 260 iterations...
--
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
19 years, 8 months
[JBoss JIRA] Commented: (JBAS-3198) Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA).
by Jim Moran (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3198?page=comments#action_12347268 ]
Jim Moran commented on JBAS-3198:
---------------------------------
This exception happens with the regular PooledInvoker as well.
There is a comment in PooledInvoker.invoke that says "// The cl on the thread should be set in another interceptor" but there does not appear to be a subsequent invoker in the standard container configurations that actually does this.
The exception only happens if a one of the classes in the isolated jar is used as a parameter to the method or in the return type of the method. An ejb with no parameters or return type does not cause this exception.
> Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA).
> -----------------------------------------------------------------------------------
>
> Key: JBAS-3198
> URL: http://jira.jboss.com/jira/browse/JBAS-3198
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: ClassLoading
> Affects Versions: JBossAS-4.0.3 SP1
> Environment: Windows XP, HP-UX 11, JDK 1.4.2 and 1.5
> Reporter: Eric Hambuch
> Assigned To: Scott M Stark
>
> When using the pooled invoker (PooledInvokerHA) in the "all" configuration with separated classloaders for each EAR (as described in Wiki:ClassLoadingConfiguration) an invocation to a bean causes confusion to the separated classloaders.
> More detailed:
> I switched from jrmpha-invoker (which creates a new thread for each request which is really bad) to pooledha invoker in a clustered environment. I have to Stateless Session Beans that share the same bean interface. Each Session Bean is deployed in a separate EAR. In "ear-deployer.xml" I switched "isolated" to "true" to separate the classloaders of the EARs.
> When I call the first bean everything works fine. But when I try to call the second bean (same interface, but different bean!) JBoss throws the following exception:
> java.rmi.ServerException: RuntimeException; nested exception is:
> java.lang.IllegalArgumentException: argument type mismatch
> at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:386)
> at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:196)
> at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:264)
> at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
> at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
> at org.jboss.ejb.Container.invoke(Container.java:873)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.invocation.pooled.server.PooledInvokerHA.invoke(PooledInvokerHA.java:146)
> at org.jboss.invocation.pooled.server.ServerThread.processInvocation(ServerThread.java:213)
> at org.jboss.invocation.pooled.server.ServerThread.dorun(ServerThread.java:268)
> at org.jboss.invocation.pooled.server.ServerThread.run(ServerThread.java:139)
> Caused by: java.lang.IllegalArgumentException: argument type mismatch
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
> at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
> at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:149)
> at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
> at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:106)
> at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:158)
> at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:62)
> at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:154)
> at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:153)
> at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
> The IllegalArgumentException comes from the fact that the Method.invoke() is called with a class of the wrong classloader (class from other EAR).
> With jrmpha-invoker everything works fine. Maybe the thread pool causes a mixture of the classloaders?
> I created a minimized example that can be provided if required.
--
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
19 years, 8 months
[JBoss JIRA] Assigned: (JBPM-682) task forms are not reloaded when a process is reloaded
by Tom Baeyens (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-682?page=all ]
Tom Baeyens reassigned JBPM-682:
--------------------------------
Assignee: David Lloyd (was: Tom Baeyens)
> task forms are not reloaded when a process is reloaded
> ------------------------------------------------------
>
> Key: JBPM-682
> URL: http://jira.jboss.com/jira/browse/JBPM-682
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Web Interface
> Affects Versions: jBPM 3.2 alpha 1
> Environment: JBoss 4.03, jBPM 3.2 cvshead, jdk 1.5
> Reporter: Ronald van Kuijk
> Assigned To: David Lloyd
> Priority: Blocker
> Fix For: jBPM 3.2
>
>
> tom: this has to do with the caching of the task forms.
> kukeltje: At first the forms seem to be 'versionable' like the process archive. When trying to use this, it does not work.
> If I have an error in a form, correct it and deploy a new process, the new form is stored in the DB. If I start a new pi for the latest pd, the previous version of the form seems to be cached by something however and used for the new process (form name stays the same). If I stop the server and start it again, start a new instance of the latest process (or load one for which I'm sure a correct form is present, the correct form is used. The tasks in older instances which should use the old forms can now be executed as well (meaning they use the new form).
--
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
19 years, 8 months
[JBoss JIRA] Updated: (JBPM-682) task forms are not reloaded when a process is reloaded
by Tom Baeyens (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-682?page=all ]
Tom Baeyens updated JBPM-682:
-----------------------------
Summary: task forms are not reloaded when a process is reloaded (was: Make forms versionable)
Issue Type: Bug (was: Feature Request)
Description:
tom: this has to do with the caching of the task forms.
kukeltje: At first the forms seem to be 'versionable' like the process archive. When trying to use this, it does not work.
If I have an error in a form, correct it and deploy a new process, the new form is stored in the DB. If I start a new pi for the latest pd, the previous version of the form seems to be cached by something however and used for the new process (form name stays the same). If I stop the server and start it again, start a new instance of the latest process (or load one for which I'm sure a correct form is present, the correct form is used. The tasks in older instances which should use the old forms can now be executed as well (meaning they use the new form).
was:
At first the forms seem to be 'versionable' like the process archive. When trying to use this, it does not work.
If I have an error in a form, correct it and deploy a new process, the new form is stored in the DB. If I start a new pi for the latest pd, the previous version of the form seems to be cached by something however and used for the new process (form name stays the same). If I stop the server and start it again, start a new instance of the latest process (or load one for which I'm sure a correct form is present, the correct form is used. The tasks in older instances which should use the old forms can now be executed as well (meaning they use the new form).
> task forms are not reloaded when a process is reloaded
> ------------------------------------------------------
>
> Key: JBPM-682
> URL: http://jira.jboss.com/jira/browse/JBPM-682
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Web Interface
> Affects Versions: jBPM 3.2 alpha 1
> Environment: JBoss 4.03, jBPM 3.2 cvshead, jdk 1.5
> Reporter: Ronald van Kuijk
> Assigned To: Tom Baeyens
> Priority: Blocker
> Fix For: jBPM 3.2
>
>
> tom: this has to do with the caching of the task forms.
> kukeltje: At first the forms seem to be 'versionable' like the process archive. When trying to use this, it does not work.
> If I have an error in a form, correct it and deploy a new process, the new form is stored in the DB. If I start a new pi for the latest pd, the previous version of the form seems to be cached by something however and used for the new process (form name stays the same). If I stop the server and start it again, start a new instance of the latest process (or load one for which I'm sure a correct form is present, the correct form is used. The tasks in older instances which should use the old forms can now be executed as well (meaning they use the new form).
--
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
19 years, 8 months
[JBoss JIRA] Commented: (EJBTHREE-527) Websphere MQ cannot be integrated with EJB3 (deployment fails)
by Michael Grübsch (JIRA)
[ http://jira.jboss.com/jira/browse/EJBTHREE-527?page=comments#action_12347258 ]
Michael Grübsch commented on EJBTHREE-527:
------------------------------------------
Elias, you might be right. I already know that I had forgotten to link the MDB back to the RAR via the JBoss specific deployment configuration in jboss.xml. However, I have observed that depending on some "arbitrary EJB3 artefacts" (here: the file persistence.xml into the META-INF) an application is succuessfully deployed or not. When neither persistence.xml exists nor any other EJB3 artefact is given, the configuration binds the administrative object QUEUE at the WebSphere queue, while in the other case (when persistence.xml exists) the QUEUE is bound to a generic JBoss queue.
> Websphere MQ cannot be integrated with EJB3 (deployment fails)
> --------------------------------------------------------------
>
> Key: EJBTHREE-527
> URL: http://jira.jboss.com/jira/browse/EJBTHREE-527
> Project: EJB 3.0
> Issue Type: Bug
> Affects Versions: EJB 3.0 RC6 - PFD
> Environment: Windows XP, JBoss 4.0.4 CR2 with EJB3 RC6
> Reporter: Michael Grübsch
>
> When trying to integrate Websphere MQ with an EJB 3 application the following exception occurs while deploying the application:
> 12:28:10,906 WARN [ServiceController] Problem starting service jboss.j2ee:jar=wsmqmdb.jar,name=MDB,service=EJB3
> java.lang.ClassCastException: com.ibm.mq.jms.MQQueue
> at org.jboss.mq.SpyConnectionConsumer.<init>(SpyConnectionConsumer.java:107)
> at org.jboss.mq.SpyConnection.createConnectionConsumer(SpyConnection.java:209)
> at org.jboss.ejb3.mdb.MDB.innerCreateQueue(MDB.java:530)
> at org.jboss.ejb3.mdb.MDB.innerCreate(MDB.java:454)
> at org.jboss.ejb3.mdb.MDB.innerStart(MDB.java:267)
> at org.jboss.ejb3.mdb.MDB.start(MDB.java:256)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.ejb3.ServiceDelegateWrapper.startService(ServiceDelegateWrapper.java:99)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> ....
> To reproduce the bug do the following:
> 1. set up environment JBoss 4.0.4 CR2 with EJB3 RC6
> 2. Download wsmqdemo.zip from the integration tutorial http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingWebSphereMQSeriesWithJBossA... (http://wiki.jboss.org/wiki/attach?page=UsingWebSphereMQSeriesWithJBossASP...)
> 3. Configure it for using Websphere for inbound and outbound (see http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingWebSphereMQSeriesWithJBossA...)
> 4. put a valid file "persistence.xml" into the META-INF directory of the application or tag some class using a @Stateful annotation (indicating that EJB3 is to be used(?))
> 5. deploy the application
--
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
19 years, 8 months
[JBoss JIRA] Resolved: (JBCACHE-644) FileCacheLoader fails if FQN contains illegal/too many characters
by Galder Zamarreno (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-644?page=all ]
Galder Zamarreno resolved JBCACHE-644.
--------------------------------------
Resolution: Done
Substituting invalid characters for invalid characters would be quite an
overhead for FCL.
If you wanna avoid portability issues, don't use certain characters which
are not recommended for FCL or Fqn.
As a result, warnings are being logged so that users are aware that
using some of the characters could affect the portability of their application:
- When creating an FCL root location, check for any non portable
characters throwing a warning. Checks '*' '<' '>' '|' '"' '?'
- When storing attributes, check that the Fqn tree does not contain non
portable characters. Checks '*' '<' '>' '|' '"' '?' and also '\' '/' and ':'
- When storing attributes as well, check for entire path that could be
bigger than 255 characters throwing a warning.
> FileCacheLoader fails if FQN contains illegal/too many characters
> -----------------------------------------------------------------
>
> Key: JBCACHE-644
> URL: http://jira.jboss.com/jira/browse/JBCACHE-644
> Project: JBoss Cache
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Cache loaders
> Affects Versions: 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4beta, 1.3.0.GA, 1.2.4, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2
> Environment: Windows XP
> Reporter: Amit Kasher
> Assigned To: Galder Zamarreno
> Fix For: 2.0.0.GA
>
> Time Spent: 4 hours
> Remaining Estimate: 0 minutes
>
> When putting FQNs that are too long to become filenames, or that contain illlegal characters for filenames (semicolon, for example), the FileCacheLoader throws an IOException.
> The FileCacheLoader should encode the FQN string so that it is a valid filename.
--
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
19 years, 8 months