[JBoss ESB Development] - Re: SOAPProxy+AS5: INVM contract unavailable w/classpath URI
by dward
"Kevin.Conner(a)jboss.com" wrote : Second, these processors need to be scoped correctly with their deployments otherwise they will never be guaranteed to load required resources/classes (for example during transformation) and this has probably existed since they were introduced. This could affect both as4 and as5 deployments, especially if the esb was scoped
When you say "these processors", what are you referring to here?
The reason the Http Gateway works in showing the WSDL is because during the HttpGatewayServlet init() method, the LifecycleResource mechanism is used to load the WSDL from the classpath, then the servlet caches the WSDL for when it is called with a "?wsdl" query string.
However, in the case of using the JBR Gateway (note: INVM no longer an issue - see above), the contract.jsp is used to serve up the WSDL. It doesn't have a "place" to hold onto the WSDL like the HttpGatewayServlet does. When contract.jsp (the "processor" in this case) invokes the WSDL loader, the web tier's classloader is used. Obviously it won't be able to "see" the wsdl file URL resource in the ESB archive.
What would you suggest doing here? Can we document that if you are using a classpath:// URI, and you are exposing an HTTP endpoint, that you should simply replace your JBR Gateway with an HTTP Gateway? That will always work. And if they click on the contract link with the JBR Gateway, that we warn them there as well (as described above)? Lemme know; thanks.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270312#4270312
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270312
15 years
[JMX Development] - security context issue with RMIAdaptor
by qihong87
Hi JBoss developers,
I'm trying to get user groups info in the mbean code w/ JBoss app server version 5.1.0 GA. After some try and error, this info is available through 'SecurityAssociation.getSubject()' and/or 'SecurityContextAssociation.getSecurityContext()'. If invoke mbean via jmx-console (the web UI), it works fine. But if invoke via RMIAdaptor with AuthenticationInterceptor enabled (following instruction at http://www.jboss.org/community/wiki/SecureTheInvokers), then 'SecurityAssociation.getSubject()' returns null, and 'SecurityContextAssociation.getSecurityContext()' returns the security context with securityDomain=other, the expected is securityDomain=jmx-console. Noticed thtat SecurityAssociation.getPricipal()/getCredential() still returns correct username and password.
After debugging, found that AuthenticationInterceptor.invoke() set the right security context before invoking, but InvokerAdaptorService.invoke() (down the interceptor chain) set the security context to the default security domain. Is this a bug or there's some reason for this?
Here's the related code in InvokerAdaptorService.invoke() line 228
// Invoke the MBeanServer method via reflection
Method method = invocation.getMethod();
Object[] args = invocation.getArguments();
Principal principal = invocation.getPrincipal();
Object credential = invocation.getCredential();
Object value = null;
SecurityContext sc = SecurityActions.createSecurityContext(SecurityConstants.DEFAULT_APPLICATION_POLICY);
SecurityActions.setSecurityContext(sc);
// Associate the method
SecurityActions.pushSubjectContext(principal, credential, null);
Note that it always use default security domain, and pass null as subject to the SecurityActions.pushSubjectContext() call.
Thanks you so much!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270310#4270310
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270310
15 years
