Access remote bean with JNDI from remote system
by Karsten Ohme
Hi,
I want to access a Bean remotely (with JNDI). So I thought I could
access in on the client with:
Properties env = new Properties();
env.put(Context.PROVIDER_URL, "jnp://myserver:1099");
Context jndiContext = new InitialContext(env);
jndiContext.lookup(...);
If I do a port scan on "myserver" the JNDI port 1099 does not show up. I
thought this is the default port. What do I have to do the get access
the remote bean?
Is there somewhere a documentation how to access JNDI resources from
another system?
Regards,
Karsten
16 years, 8 months
[JBossWS] - Seam 2.0.1 & JBossWS & WAR deployment
by cardel
The Seam reference explains how to configure and package a Seam EAR to support JBossWS web services. That worked great.
However, I have not been able to get JBossWS to work with a Seam WAR deployment.
I have Seam 2.0.1, JBoss AS 4.2.2 GA and JBossWS 2.0.3 GA
I created this service interface:
| import javax.jws.WebMethod;
| import javax.jws.WebParam;
| import javax.jws.WebResult;
| import javax.jws.WebService;
| import javax.jws.soap.SOAPBinding;
| import javax.jws.soap.SOAPBinding.Style;
|
| @WebService(name = "TestEndpoint", serviceName = "HcpService")
| @SOAPBinding(style = Style.RPC)
| public interface TestEndpoint
| {
| @WebMethod
| @WebResult(name = "result")
| public String echo(@WebParam(name = "message") String msg);
| }
|
and service implementation:
| import javax.jws.WebMethod;
| import javax.jws.WebParam;
| import javax.jws.WebResult;
| import javax.jws.WebService;
| import javax.jws.soap.SOAPBinding;
| import javax.jws.soap.SOAPBinding.Style;
|
| import org.jboss.seam.Component;
| import org.jboss.seam.security.Identity;
|
| @WebService(name = "TestEndpoint", serviceName = "HcpService")
| @SOAPBinding(style = Style.RPC)
| public class TestEndpointBean
| {
|
| @WebMethod
| @WebResult(name = "result")
| public String echo(@WebParam(name = "message") String msg)
| {
| return "Echo " + msg;
| }
| }
|
I donôt know if my procedure was fine, but to make the webservice working I had to add servlet to web.xml
<servlet>
| <servlet-name>TestEndpoint</servlet-name>
| <servlet-class>hcp.TestEndpointBean</servlet-class>
| </servlet>
|
| <servlet-mapping>
| <servlet-name>TestEndpoint</servlet-name>
| <url-pattern>/test</url-pattern>
| </servlet-mapping>
|
Only with this servlet is after deployment service endpoint registered and visible in browser (http://localhost:8080/jbossws/services)
At first I had setProperty must be overridden by all subclasses of SOAPMessage exception, so I switched to java 1.5 to get rid of it.
After this, my webservice is active and I can successfully send requests and receive responses.
But now I have another problem when I want to use some seam component. I have read, that I have to use Component.getInstance method. So i tried it:
| public class TestEndpointBean
| {
| @WebMethod
| @WebResult(name = "result")
| public String echo(@WebParam(name = "message") String msg)
| {
| Identity id = (Identity) Component.getInstance("org.jboss.seam.security.identity");
| id.setUsername(msg);
| id.setPassword(msg);
| id.login();
| if (id.isLoggedIn()) {
| return "Logged in";
| } else {
| return "Not logged in";
| }
| }
| }
|
But after invoke the request I have this exception :-(
| 23:42:04,890 ERROR [SOAPFaultHelperJAXWS] SOAP request exception
| java.lang.IllegalStateException: No application context active
| at org.jboss.seam.Component.forName(Component.java:1807)
| at org.jboss.seam.Component.getInstance(Component.java:1857)
| at org.jboss.seam.Component.getInstance(Component.java:1840)
| at org.jboss.seam.Component.getInstance(Component.java:1834)
| at hcp.TestEndpointBean.echo(TestEndpointBean.java:47)
| 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.wsf.container.jboss42.DefaultInvocationHandler.invoke(DefaultInvocationHandler.java:102)
| at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:222)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:418)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:274)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:191)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:124)
| at org.jboss.wsf.stack.jbws.EndpointServlet.service(EndpointServlet.java:84)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
| at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
| at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
| at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
| at java.lang.Thread.run(Thread.java:595)
| 23:42:04,890 ERROR [SOAPFaultHelperJAXWS] SOAP request exception
| java.lang.IllegalStateException: No application context active
| at org.jboss.seam.Component.forName(Component.java:1807)
| at org.jboss.seam.Component.getInstance(Component.java:1857)
| at org.jboss.seam.Component.getInstance(Component.java:1840)
| at org.jboss.seam.Component.getInstance(Component.java:1834)
| at hcp.TestEndpointBean.echo(TestEndpointBean.java:47)
| 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.wsf.container.jboss42.DefaultInvocationHandler.invoke(DefaultInvocationHandler.java:102)
| at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:222)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:418)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:274)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:191)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:124)
| at org.jboss.wsf.stack.jbws.EndpointServlet.service(EndpointServlet.java:84)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
| at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
| at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
| at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
| at java.lang.Thread.run(Thread.java:595)
Any suggestions?
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133392#4133392
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133392
16 years, 9 months
[JBoss/Spring Integration] - Re: JBOSS5 + Spring Deployer version confusion
by alesj
"dlmiles" wrote :
| I am correct in thinking the above version is for JBoss AS 4.2.x and older ? But should not be used wit JBoss AS 5 ?
|
Yes, only JBossAS 4.x.
"dlmiles" wrote :
| Should something appear in the JBossAS console log ?
|
If you use trace log for deployers packages, there should be some log indicating that deployer was added to MainDeployersImpl/DeployersImpl.
"dlmiles" wrote :
| I am correct in thinking this should be used with JBoss AS 5 and newer ?
|
Yes, it's the new breed of deployers. :-)
"dlmiles" wrote :
| Now if I wanted to upgrade to 2.0.7 or 2.0.8 is a recompile necessary or can I replace the spring-*.jar files inside the jboss-spring.deployer file ?
|
It depends on the back (or in this case fwd) compatibility of Spring lib.
I had no problems changing between 2.0.8 and 2.5.
"dlmiles" wrote :
| Could I also suggest that all dependent JARs what are bundled please use the file name that includes the version of said file like "spring-core-2.0.99.jar" not just the plain "spring-core.jar" so its really clear to audit.
|
You can suggest :-), but I'm not gonna do that. ;-)
Those are Spring files as such, I don't wanna modify them in any way.
And you can see the version in its manifest.mf file.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133371#4133371
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133371
16 years, 9 months
[Remoting] - SocketClientInvoker Doesn't Catch/Throw Transaction Timeouts
by jcreynol
Please see discussion thread in JBoss Transactions forum, here.
Essentially, the issue is this:
We had a project where we converted from a Swing Client-Server App from WebLogic 8.1 (EJB2) to JBoss 4.2 and were advised by JBoss Consultants onsite that Socket connectors perform better than RMI and will handle failover better in moving away from a Clustered environment to multiple servers behind a Virtual IP (using ClientConnectAddress in jboss-service.xml to spoof clients). So we need to stick with Sockets, if possible, but...
When we change our org.jboss.remoting.transport.Connector in our jboss-service.xml from transport=socket to transport=rmi, we actually get the behavior we'd hope to see under socket. (though lose some desired behavior that socket provides)
Under RMI, when the transaction timesout, the client is immediately notified that the transaction was timedout/rolledback. Under Socket, the thread that is wrapped in the transaction actually finishes before anything is sent back to the client -- even after the transaction timed out and rolled back! So the user gets an IllegalStateException returned after waiting for the entire thread to complete.
Not the best design, but we have always counted on the transaction timeout/rollback error to notify the client immediately. Imagine a user fires off a query to load a list of tasks and they accidentally enter in a date range much larger than they intended. (granted, we could control some more at the client level, but ideally we would make this conversion to jboss w/o having to change too much of this long-standing code) Under RMI, we can send a message back to the user after 5 or 10 minutes, so they can see that the transaction timed out and clean up the query or otherwise try something else.
Under Socket, the behavior is far less desirable. Say the query runs for 12 minutes with a transaction timeout of 5 minutes. The transaction dies after 5 minutes but the end user on the client side doesn't receive a notification and instead is left to watch the status bar bounce for another 7 minutes... and at that time they don't even receive their result set, they get an IllegalStateException! (we could adjust our timeout, but that's not what the users are used to and we'd ultimately like to keep some consistency after the migration from weblogic to jboss)
What can be done to get Socket transport behaving like RMI transport? (i.e. sending a transaction timeout/rollback exception back to the client)
Thanks much, in advance, for any and all assistance!
-John
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133370#4133370
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133370
16 years, 9 months
