EJB runtime statistics through web-console throws Exceptions

[subcommandante_m]

Hi there,

on porting an application from JB4.0.3SP1 to JB4.0.4 and testing it the following occurs by invoking the runtime stats at J2EE Domains:

09:26:52,140 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception
javax.servlet.jsp.JspTagException: org.jboss.mx.util.MBeanProxyCreationException
: Object name jboss.j2ee:service=EJB,jndiName=CustomerProcess not found: javax.m
anagement.InstanceNotFoundException: jboss.j2ee:service=EJB,jndiName=CustomerPro
cess is not registered.
at org.jboss.console.plugins.helpers.servlet.MBeanTag.doStartTag(MBeanTa
g.java:95)
at org.apache.jsp.StatelessEjb_jsp._jspService(StatelessEjb_jsp.java:110
)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper
.java:332)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3
14)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFi
lter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(Securit
yAssociationValve.java:175)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValv
e.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p
rocessConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo
int.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWor
kerThread.java:112)
at java.lang.Thread.run(Unknown Source)

Client accesses the beans perfectly, jndi-view already checked, has worked perfectly with JB4.0.3 !!

Any glues? Thx in advance

Marcos

[subcommandante_m]

Hi !

Maybe I forgot to mention, that this is a critical issue, even for the customer who is about migrating an existing application from another - commercial - app.-server. Operating is the issue, not development.

No one else around here with the same problem, no one of jboss who could answer or could give a hint ...

Marcos

[peterj]

Have you checked the jmx-console to see what mbeans are declared in the jboss.j2ee namespace? It would appear that the EJB named CustomerProcess was not deployed.

[subcommandante_m]

Hi PeterJ,

the application runs, client accesses the bean! The Bean is deployed but under jndi-name ejb/CustomerProcess. For me it seems as if Jboss is looking up for CustomerProcess only. As mentioned, everything was working perfect under Jboss4.0.3SP1. It was simply re-deployment under Jboss4.0.4 / 4.0.5 and bang.

Marcos

[chalad]

Yeap, I seem to be having the same problem as well.
In order to get it working I removed the prefix from the JNDI name, and left the EJB name alone.

the thing is that this used to work perfectly well with previous veriosn of JBoss (< 4.0.4)

[subcommandante_m]

@chalad,

seems as we are at least two => seems to be a bug.
Removing the subcontext isn't an option in my project. As mentioned, Versions 4.0.4 and 4.0.5 have this bug.
Suprisingly no one else seems to use this feature which is essential to my customer in production. Buying 24x7 support for approx. 45.000,- isn't an option on evaluation as well.

We will see what the future brings ...

Regards

Marcos

[subcommandante_m]

What is to be read at the very first page: Ever feel like talking to yourself ?? Yep, I did using this forum.

Bye
Marcos

[starksm64]

Most likely you are running into this change in behavior for the default local jndi names which affects the mbean name.

http://wiki.jboss.org/wiki/Wiki.jsp?page=WhyDoesTheLocalNameContainARandomNumber

[dudlo]

I think Scott misunderstood the nature of this problem. This is not an "I can't look up my MBean" user error, this is a bug in web-console. Most of the web-console statistics displayed for an EJB is not available because of the bug.

It is easy to replicate even with the "JBoss AS Getting Started Guide" tutorial example. Just follow the example and deploy it to a 4.0.4.GA or 4.0.5.GA or 3.2.8.SP1 server. Then open web-console (http://localhost/web-console and navigate to J2EE Domains -> Manager -> JBoss -> JBossDukeBank.ear -> bank-ejb.jar -> MyAccountController. You'll get the error (MBeanProxyCreationException).

The error does not happen in 3.2.7 or 4.0.3SP1 releases. I noticed that the JSPs of the web-console have been touched after these releases. But it is the left sidenavigation applet that is causing the error (passing wrong JMX name into the JSP).

In most cases (as reported above), it can be worked around by using simple JNDI names (local and global) like MyEJB, instead of com/acme/MyEJB. When I use the fully qualified JNDI name, it shows correctly in the old web-console (under the jar, it shows as com/acme/MyEJB). In the buggy one, the name is stripped and only the last node name (MyEJB) is shown. However, as you can see in the tutorial example, even using simple names does not work all the time.

Again, please treat this as web-console internal error.