[JBoss JIRA] Closed: (JBAS-13) Fix the java5 testsuite errors
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-13?page=all ]
Dimitris Andreadis closed JBAS-13.
----------------------------------
> Fix the java5 testsuite errors
> ------------------------------
>
> Key: JBAS-13
> URL: http://jira.jboss.com/jira/browse/JBAS-13
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: JBossAS-4.0.0 Final
> Environment: [starksm@banshee9100 testsuite]$ /usr/java/jdk1.5.0/bin/java -version
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
> Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode)
> Reporter: Scott M Stark
> Assigned To: Scott M Stark
> Fix For: JBossAS-4.0.1 Final
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> There are still some failures when running the testsuite under java5 that need to be corrected for the 4.0.1 release. This task contains the subtasks in the java5 testsuite run.
--
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, 3 months
[JBoss JIRA] Created: (JBCACHE-880) Add expiration policy for nodes based on a node's expiration key
by Elias Ross (JIRA)
Add expiration policy for nodes based on a node's expiration key
----------------------------------------------------------------
Key: JBCACHE-880
URL: http://jira.jboss.com/jira/browse/JBCACHE-880
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Elias Ross
Assigned To: Manik Surtani
It is useful to specify an expiration time (TTL) for cache values individually. For example, in caching web page contents, the data should be retained based on the HTTP header "Expires". Or, for caching session data, it should be kept based on the user's preference, e.g. Yahoo! Mail allows the authentication credentials to be cached from 1-24 hours.
Example usage:
TreeCache cache;
Fqn fqn1 = new Fqn("node1");
Fqn fqn2 = new Fqn("node2");
cache.put(fqn1, "expiration", new Long( ... ));
cache.put(fqn1, "data", ... );
cache.put(fqn2, "expiration", new Long( ... ));
cache.put(fqn2, "data", ... );
--
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, 4 months
[JBoss JIRA] Resolved: (JBAS-3198) Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA).
by Tom Elrod (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3198?page=all ]
Tom Elrod resolved JBAS-3198.
------------------------------
Resolution: Done
Fix has been applied to (including addition to testsuite for first three):
https://svn.jboss.org/repos/jbossas/branches/Branch_4_0
https://svn.jboss.org/repos/jbossas/branches/Branch_4_2
https://svn.jboss.org/repos/jbossas/trunk
https://svn.jboss.org/repos/jbossas/branches/JBoss_4_0_2_CP
https://svn.jboss.org/repos/jbossas/branches/JBoss_4_0_5_GA_CP
https://svn.jboss.org/repos/jbossas/branches/JBoss_4_0_2_JBAS-3912
https://svn.jboss.org/repos/jbossas/branches/JBoss_4_0_5_GA_JBAS-3913
> 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.5.CR1
> Environment: Windows XP, HP-UX 11, JDK 1.4.2 and 1.5
> Reporter: Eric Hambuch
> Assigned To: Tom Elrod
> Priority: Critical
> Fix For: JBossAS-5.0.0.CR1, JBossAS-4.2.0.CR1, JBossAS-4.0.5.SP1
>
> Attachments: example.zip
>
>
> 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, 4 months
[JBoss JIRA] Created: (JBPORTAL-1180) Running jsf-portlets (SUN RI) on JBoss Portal 2.2.1
by Herv← Minko (JIRA)
Running jsf-portlets (SUN RI) on JBoss Portal 2.2.1
---------------------------------------------------
Key: JBPORTAL-1180
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1180
Project: JBoss Portal
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 2.2.1 Final
Environment: Windows XP, JBOSS 4.0.3SP1
Reporter: Herv← Minko
Priority: Critical
I removed all myFaces libraries from tomcat, and JSF Applications run properly on JBoss. Now i am trying to run a jsf-portlet (SUN RI) on JBoss portal 2.2.1. As long as the attribute UseJBossWebLoader is set to false, i get an exception by deploying my jsf-portlet.
After setting UseJBossWebLoader (jboss-service.xml) to true, the jsf-portlets run, but other normal jsf applications don t run any more. So how can i run jsf-portlets on jboss portal without setting UseJBossWebLoader to true?
--
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, 4 months