[Beginner's Corner] - Shutdown -e 10 not working in JBoss 5.1
by rm＠cochrane.dk
Shutdown -e 10 (to restart the server) does not seem to be working in JBoss 5.1. This used to work in JBoss 4.2. How can you restart JBoss 5 programmatically?
Thanks,
Rasmus
| C:\jboss-5.1.0\bin>shutdown -e 10
| Exception in thread "main" java.lang.reflect.UndeclaredThrowableException
| at $Proxy1.exit(Unknown Source)
| at org.jboss.Shutdown.main(Shutdown.java:234)
| Caused by: javax.management.ReflectionException
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
| java:231)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
| java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
| sorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:592)
| at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerA
| daptorService.java:263)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
| java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
| sorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:592)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
| er.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
| or.java:138)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
| BeanOperationInterceptor.java:140)
| at org.jboss.jmx.connector.invoker.SerializableInterceptor.invoke(Serial
| izableInterceptor.java:74)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
| java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFac
| tory.java:180)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
| java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
| sorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:592)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
| er.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
| java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke
| (JRMPInvoker.java:855)
| at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:
| 422)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
| java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
| sorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:592)
| at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
| at sun.rmi.transport.Transport$1.run(Transport.java:153)
| at java.security.AccessController.doPrivileged(Native Method)
| at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
| at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:4
| 66)
| at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport
| .java:707)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.lang.IllegalArgumentException: Unable to find operation exit(int
| )
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254270#4254270
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254270
15 years, 4 months
[JBoss Portal Users] - Global logoff
by dawebster
This should be a common problem in the portal world. I have four portlets in a portal page that are actually apps hosted in four different containers, EWS, EAP, etc...., each with it's own session to that container managed via a JSESSIONID cookie, all named, of course, jsessionid, but with custom cookie paths to enable apache to properly route requests and apply sticky-session attributes.
Problem is how to provide a single logout button that will invalidate/delete the sessions (jsessionid) cookies of each app in the portal page.
We do not want users to have to logout of each app or close their browser. Problem today is the global logout (implemented as it's own little app) can only log itself out, the sessions of the portal's apps remain intact on the respective servers. Another user comes along (the are kiosk machines in the field used by many different users) and they get the user before them's sessions instead of new ones, becasue the browser is still maintaining the old session cookies to each app and the sessions are still active on the server-side?
We can alter the default name of the session cookie on each server host to something other than jsessionid and do away with custom cookie paths, but Tomcat does not recommend doing that as it is a violation of the servlet spec?
Any other ideas out there?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254268#4254268
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254268
15 years, 4 months
[JBoss Remoting Users] - JNDI Lookup in multi-classloader environment
by praveenbalaji
Software Version: JBoss Client from JBoss 4.2.2 drop.
I'm trying to do a JNDI lookup of a JMS Connection Factory in my component. This is a plain Java component. Several of my componnets can run in the same JVM under different classloaders. I'm loading jboss client jars in each of these component classloaders such that each classloader has its own copy of client jars. Each component does a JNDI lookup for the same named object.
The second (and consequent) component that does a lookup fails with a ClassCastException. The second component is looking up an object created by the first component. Though the classname matches, the classloader is different and hence the ClassCastException.
| caused by: javax.naming.NamingException: Could not dereference object [Root exception is java.lang.ClassCastException: org.jboss.naming.LinkRefPair]
| at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1298)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:763)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
| at javax.naming.InitialContext.lookup(InitialContext.java:351)
| ...
| ...
| at sun.rmi.transport.Transport$1.run(Transport.java:153)
| at java.security.AccessController.doPrivileged(Native Method)
| at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
| at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
| at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.lang.ClassCastException: org.jboss.naming.LinkRefPair
| at org.jboss.naming.LinkRefPairObjectFactory.getObjectInstance(LinkRefPairObjectFactory.java:66)
| at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
| at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1273)
| at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1290)
| ... 70 more
|
I looked at the JBoss code and the object returned by the lookup at org.jnp.interfaces.NamingContext.lookup(javax.naming.Name) (line 667) is fetching the offending object.
Is there a way to provide isolation at component level in the client code? I see there is a way to do it for components (enterprise applications) running under the J2EE container as stated at http://www.jboss.org/community/wiki/classloadingconfiguration
Please note that unfortunately for me, it is not an option for me to load the jboss client jars under the JRE's ext classloader which is the ancestor of all my component classloaders. I have to provide isolation at the component level.
Thanks
Praveen
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254263#4254263
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254263
15 years, 4 months