[JBoss JIRA] Created: (JBRULES-1568) Java debug not working with multiple rule files
by Kris Verlaenen (JIRA)
Java debug not working with multiple rule files
-----------------------------------------------
Key: JBRULES-1568
URL: http://jira.jboss.com/jira/browse/JBRULES-1568
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Eclipse IDE
Reporter: Kris Verlaenen
Assigned To: Kris Verlaenen
Fix For: 4.0.7
There is an issue with rule breakpoints (in Java dialect) when rules from multiple rule files are loaded.
The generated java consequence class contains not only the imports of its own file but also those of all other rules in the package.
Therefore, the generated code can be different depending on the context the rules are used in.
As a consequence, it is impossible to predict the exact line number in the generated java consequence class,
necessary for debugging.
This issue can be fixed by making sure all imports are on one and the same line.
--
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, 2 months
[JBoss JIRA] Created: (JBAS-5026) NPE in JvmRouteVale.handleJvmRoute
by Philippe Sevestre (JIRA)
NPE in JvmRouteVale.handleJvmRoute
----------------------------------
Key: JBAS-5026
URL: http://jira.jboss.com/jira/browse/JBAS-5026
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-4.2.1.GA
Environment: https + apache 2.0.52 + mod_jk + jboss + ClusteredSSO
Reporter: Philippe Sevestre
Assigned To: Remy Maucherat
Client is a rich app (swing) that does soap calls to an app. Some of those WebServices are secured by a "BASIC" security constraint.
When client calls the first password protected service, JBoss tries to set SSO and Session cookies. Then client make some more non-restricted calls that work just fine. After that, the first secured call fails with a NPE at JvmRouteValve, detailed bellow:
2007-11-30 18:16:36,144 ERROR [org.apache.catalina.connector.CoyoteAdapter] An exception or error occurred in the container during the request processing
java.lang.NullPointerException
at org.jboss.web.tomcat.service.session.JvmRouteValve.handleJvmRoute(JvmRouteValve.java:125)
at org.jboss.web.tomcat.service.session.JvmRouteValve.checkJvmRoute(JvmRouteValve.java:112)
at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:81)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn.invoke(ClusteredSingleSignOn.java:637)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
Checking the code, the only way I see that this could happen is when checkJvmRoute passes a null to handleJvmRoute on its first parameter (oldsessionId). In turn, this implies that getRequestedSessionId() returned null AND getSession(false) didn't.
What I can see from packet dumps in the APJ connection is that the client is *not* passing a JSESSIONID header along the call, but, since all calls use *the same tcp/ip connection*, it seems that the session manager still "remembers" that it has a session. Therefore, in this scenario, oldessionId == null (since the client didn't send any session cookie) and session !=null, causing this NPE.
A simple fix would be test oldsessionId for null at line 91, returning if it is.
--
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, 2 months