[JBoss JIRA] Created: (EJBTHREE-823) Unable to call ejb remotely
by Sureshbabu Thyvalappil (JIRA)
Unable to call ejb remotely
---------------------------
Key: EJBTHREE-823
URL: http://jira.jboss.com/jira/browse/EJBTHREE-823
Project: EJB 3.0
Issue Type: Bug
Environment: JBOSS 4.0.5 with EJB 3.0
Reporter: Sureshbabu Thyvalappil
I'm using JBOSS 4.0.5GA with ejb3. I am running into weird behavior when running java client from remote machine. If I run it from the same machine where the jboss server is running, no problem. So here is the behavior I'm noticing.
FOr the jndi lookup of ejb, it is connecting the remote server and gets a reference to the ejb. But when I call a method on the ejb reference, it is trying to call a method on the local machine( I mean the same machine where the client is running).
Sounds very weird to me. Any help is appreciated from EJB3 experts.
I upgraded to EJB3 RC9 patch1, but same behavior.
Here is the client code ..
try
{
Properties p=new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
p.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
p.put(Context.PROVIDER_URL,"jnp://remote-host:1099");
InitialContext ctx = new InitialContext(p);
IReportService report = (IReportService) ctx.lookup(
"ejb3/xxx/ReportService");
System.out.println("Got the ejb remote reference = "+report);
System.out.println("report.resubmit.."+report.resubmit(null,0L));
ReportJob reportJob = new ReportJob();
System.out.println("B4 report.submitRequest..");
report.submitRequest(reportJob);
System.out.println("After report.submitRequest..");
}
catch (Exception e)
{
e.printStackTrace();
}
--
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
18 years, 8 months
[JBoss JIRA] Created: (JBPM-835) check out jeff's bug reports
by Tom Baeyens (JIRA)
check out jeff's bug reports
----------------------------
Key: JBPM-835
URL: http://jira.jboss.com/jira/browse/JBPM-835
Project: JBoss jBPM
Issue Type: Task
Components: Core Engine
Reporter: Tom Baeyens
Assigned To: Tom Baeyens
Fix For: jBPM jPDL 3.2
When I created a project in Eclipse with jbpm-jpdl-3.2.Beta2 as the source there was a number of compilation issues. These I could resolve as follows:
1) jms example - remove or comment out the offending code. This example uses APIs that do not exist in the product.
2) org.apache.tools.ant.BuildException in src/identity/LoadIdentitiesTask required ant.jar to be added to lib
3) my rules examples require drools-compiler-3.0.5 and drools-core-3.0.5 to be added to lib
4) org.jbpm.jcr.jackrabbit.JackrabbitJcrServiceFactory requires jackrabbit-core-1.0.1 to be added to lib
--
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
18 years, 8 months
[JBoss JIRA] Created: (JBREM-717) servlet invoker illegal state exception not serializable
by John Mazzitelli (JIRA)
servlet invoker illegal state exception not serializable
--------------------------------------------------------
Key: JBREM-717
URL: http://jira.jboss.com/jira/browse/JBREM-717
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.GA (Boon)
Reporter: John Mazzitelli
Assigned To: Tom Elrod
I have my server-side using the servlet invoker (I'm inside JBossAS 4.0.5). After I shutdown and try to restart, I think I might not be restarting properly. If a client sends in a message, I get this stack trace and an HTTP 500 error comes across on the client. Here's the server-side stack:
15:59:05,510 WARN [[ServerInvokerServlet]] Servlet.service() for servlet ServerInvokerServlet threw exception
java.io.NotSerializableException: org.jboss.remoting.transport.servlet.ServletServerInvoker
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291)
at org.jboss.remoting.marshal.http.HTTPMarshaller.write(HTTPMarshaller.java:69)
at org.jboss.remoting.transport.servlet.ServletServerInvoker.processRequest(ServletServerInvoker.java:257)
at sun.reflect.GeneratedMethodAccessor183.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:201)
at $Proxy185.processRequest(Unknown Source)
at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.processRequest(ServerInvokerServlet.java:127)
at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.doPost(ServerInvokerServlet.java:156)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
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:96)
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:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
So this IllegalStateException is thrown because something didn't get restarted. But the fact that this IllegalStateException is defined inside the ServerInvoker object makes it not serializable (ServerInvoker.IllegalStateException is not serializable because ServerInvoker is not serializable).
This issue is to document the fact that this exception is not serializable - the whole "restart didn't fully restart" problem is something that may be my fault.
Recommend that you split out IllegalStateException so you can send it over the wire - or thrown a java.lang.IllegalStateException.
This is in 2.0.0.GA. I haven't tried to see if this is an issue in later versions.
--
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
18 years, 8 months
[JBoss JIRA] Created: (HIBERNATE-55) No way to specify Connection Release Mode in HMBean
by Mohammed Sadiq (JIRA)
No way to specify Connection Release Mode in HMBean
---------------------------------------------------
Key: HIBERNATE-55
URL: http://jira.jboss.com/jira/browse/HIBERNATE-55
Project: Hibernate
Issue Type: Feature Request
Reporter: Mohammed Sadiq
Assigned To: Steve Ebersole
In my application I have employed an Hibernate MBean for session factory creation and binding it to JNDI and I've added a new overload for the SessionFactory.openSession(Interceptor, ConnectionReleaseMode) method to oveeride the default connection release mode.
The default connection release mode for any Hibernate session created using the session factory deployed through a Hibernate MBean configuration is taken as "after_statement".
It will be more helpful, if there exists an MBean attribute "ConnectionReleaseMode" which can thake the enumerated values from the org.hibernate.ConnectionReleaseMode.
--
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
18 years, 8 months