[JBoss.NET] - JBoss 3.2.7 JBoss.Net: TransportAuthorizationHandler not fou
by DanielAborg
Hi,
I've just upgraded to JBoss 3.2.7 in an attempt to migrate our application to higher versions and I'm getting a rather odd exception to do with JBoss.Net.
Since the exception doesn't mention any of our code, I don't even know where to start looking for the possible cause of this. The only thing I've managed to work out is that TransportAuthorizationHandler is indeed not included in JBoss 3.2.7 - I just don't understand why the Axis servlet is trying to load it?
Any insights on this would be truly welcome.
Here's the stack trace:
| org.apache.axis.ConfigurationException: java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.net.axis.server.TransportAuthorizationHandler
| java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.net.axis.server.TransportAuthorizationHandler
| at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:275)
| at org.jboss.mx.loading.UnifiedClassLoader3.loadClassImpl(UnifiedClassLoader3.java:192)
| at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:136)
| at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
| at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
| at java.lang.Class.forName0(Native Method)
| at java.lang.Class.forName(Class.java:164)
| at org.apache.axis.utils.ClassUtils$2.run(ClassUtils.java:216)
| at java.security.AccessController.doPrivileged(Native Method)
| at org.apache.axis.utils.ClassUtils.loadClass(ClassUtils.java:179)
| at org.apache.axis.utils.ClassUtils.forName(ClassUtils.java:120)
| at org.apache.axis.deployment.wsdd.WSDDDeployableItem.getJavaClass(WSDDDeployableItem.java:418)
| at org.apache.axis.deployment.wsdd.WSDDDeployableItem.makeNewInstance(WSDDDeployableItem.java:347)
| at org.apache.axis.deployment.wsdd.WSDDDeployableItem.getNewInstance(WSDDDeployableItem.java:322)
| at org.apache.axis.deployment.wsdd.WSDDDeployableItem.getInstance(WSDDDeployableItem.java:307)
| at org.apache.axis.deployment.wsdd.WSDDChain.makeNewInstance(WSDDChain.java:167)
| at org.apache.axis.deployment.wsdd.WSDDDeployableItem.getNewInstance(WSDDDeployableItem.java:322)
| at org.apache.axis.deployment.wsdd.WSDDDeployableItem.getInstance(WSDDDeployableItem.java:307)
| at org.apache.axis.deployment.wsdd.WSDDService.makeNewInstance(WSDDService.java:483)
| at org.apache.axis.deployment.wsdd.WSDDDeployableItem.getNewInstance(WSDDDeployableItem.java:322)
| at org.apache.axis.deployment.wsdd.WSDDDeployableItem.getInstance(WSDDDeployableItem.java:307)
| at org.apache.axis.deployment.wsdd.WSDDDeployment.getService(WSDDDeployment.java:526)
| at org.jboss.net.axis.Deployment.getServiceInternal(Deployment.java:275)
| at org.jboss.net.axis.Deployment.getService(Deployment.java:293)
| at org.apache.axis.configuration.FileProvider.getService(FileProvider.java:288)
| at org.apache.axis.AxisEngine.getService(AxisEngine.java:300)
| at org.apache.axis.MessageContext.setTargetService(MessageContext.java:795)
| at org.apache.axis.handlers.http.HTTPActionHandler.invoke(HTTPActionHandler.java:121)
| at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:73)
| at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:160)
| at org.apache.axis.SimpleChain.invoke(SimpleChain.java:123)
| at org.apache.axis.server.AxisServer.invoke(AxisServer.java:304)
| at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:975)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
| at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:370)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
| at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
| at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
| at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
| at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
| at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66)
| at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:162)
| at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:540)
| at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
| at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
| at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
| at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
| at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
| at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
| at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
| at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
| at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
| at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
| at java.lang.Thread.run(Thread.java:595)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986296#3986296
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986296
19Â years, 7Â months
[JBoss Portal] - Re: Seeking answers to a few questions about JBoss & WSRP
by chris.laprunï¼ jboss.com
Hi Pekka,
"muted" wrote :
| Is mandatory registration already possible and the documentation just doesn't reflect this yet or are there any patches or hotfixes/hacks that would enable us to require registration for the WSRP customers? The system we're planning on implementing would require a mandatory registration scheme.
|
As specified in the documentation, registration on the producer side is not currently supported. It will be, however, as part of Portal 2.6. An alpha release containing this feature will be released by the end of 2006. I'd be interested in learning about your use cases though and how you intend to implement WSRP for your customers.
"muted" wrote :
| This is more of a general portlet/WSRP question. We haven't had time to test WSRP in action yet, we've just focused on creating some proof-of-concept portlets running on JBoss. When a user logs in to the WSRP customer's portal, am I correct in assuming that any setAttribute/getAttribute, getRemoteUser and similar-methods invoked in the RenderRequest will be based on the WSRP customer's session data. The reason I'm asking is that the system would use some data from the WSRP customer's user database to focus back-end searches on the corrent datasets.
I am not sure I understand your question properly. When you are talking of the "WSRP customer's session data" what exactly are you refering to? In JBoss Portal, a WSRP portlet (i.e. a portlet that happens to be located on a remote portal and interacted with via WSRP) is considered as a regular portlet. What this implies is that if you log into the portal that consumes remote portlets (the consumer) with a given identity, this will be the identity that will be propagated to the portlet via WSRP as long as it is covered by the WSRP protocol. Does that answer your question?
Let us know if you need more information.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986292#3986292
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986292
19Â years, 7Â months