GowriSankar Narayanaswamy

Greenhorn
+ Follow
since Mar 31, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by GowriSankar Narayanaswamy

GowriSankar Narayanaswamy wrote:
Here is the stack trace i get in jboss console for the second application after invoking the ejb.
21:11:29,574 ERROR [[action]] Servlet.service() for servlet action threw exception
javax.ejb.AccessLocalException: SecurityException; CausedByException is:
No matching username found in Principals
at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:366)



Well, we did four changes:
1. We had to upgrade to Jboss 5.1.0, when we ported our application to FreeBSD. [Guess this upgrade has nothing to do with the issue]
2. When we did that, we found that there is a property in jboss that can be used to tell the class loader to treat classes in each ear file separately. It is in JBOSS_HOME/server/default/deployers/ear-deployer-jboss-beans.xml. [We replaced "default" with our installation specific name, "demo", so that it becomes JBOSS_HOME/server/demo/deployers/ear-deployer-jboss-beans.xml]. Last section in the file normally has:
<bean name="EARClassLoaderDeployer" class="org.jboss.deployment.EarClassLoaderDeployer">
<property name="isolated">false</property>
</bean>
We changed it to
<bean name="EARClassLoaderDeployer" class="org.jboss.deployment.EarClassLoaderDeployer">
<property name="isolated">true</property>
</bean>

3. We made changes to login-config.xml, so that it chains all authentication requests from one EAR's authentication to another.
4. We made application specific changes, which were earlier in global context to .EAR specific (e.g., data source name, JNDI name, etc.,) [I'm pretty sure, this had only minor impact and we knew that this has to be done, anyway].
13 years ago
Here is the stack trace i get in jboss console for the second application after invoking the ejb.

21:11:29,574 ERROR [[action]] Servlet.service() for servlet action threw exception
javax.ejb.AccessLocalException: SecurityException; CausedByException is:
No matching username found in Principals
at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:366)
at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:125)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:93)
at org.jboss.ejb.SessionContainer.internalInvokeHome(SessionContainer.java:613)
at org.jboss.ejb.Container.invoke(Container.java:894)
at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:344)
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:118)
at $Proxy284.create(Unknown Source)
at com.xyz.AdminLookup.getXyzUserSessionBean(Unknown Source)
at com.xyz.ui.xyzLogonAction.execute(Unknown Source)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
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:81)
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.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
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:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
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)
javax.security.auth.login.FailedLoginException: No matching username found in Principals
at org.jboss.security.auth.spi.DatabaseServerLoginModule.getUsersPassword(DatabaseServerLoginModule.java:126)
at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:182)
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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:572)
at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:506)
at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:315)
at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:196)
at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:120)
at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:121)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:93)
at org.jboss.ejb.SessionContainer.internalInvokeHome(SessionContainer.java:613)
at org.jboss.ejb.Container.invoke(Container.java:894)
at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:344)
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:118)
at $Proxy284.create(Unknown Source)
at com.xyz.AdminLookup.getXyZUserSessionBean(Unknown Source)
at com.xyz.ui.xyzLogonAction.execute(Unknown Source)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
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:81)
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.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
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:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
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)
[ October 31, 2007: Message edited by: GowriSankar Narayanaswamy ]
16 years ago
We have to deploy two instances of same application (.ear files) running in a single jboss server (so that we can use virtual hosting later). We are using jboss 4.0.3 sp1.

Our application has:
. Local EJBs
. Struts accessing the EJBs
. JSPs
using Database authentication.

Each application has its own database, data sources and unique jndi names configured to be accessed properly by the respective application war. Each application is deployed using its own context root. (http://localhost:8080/first and http://localhost:8080/second).

If we deploy application "first" only, it works fine (using say, first.ear). If we deploy application "second" (using say, second.ear) only, it works fine. If we deploy both, then "first" only works. We get a "No username found in principals" exception for second.

We stopped jboss server and renamed "first.ear" to "xyz.ear". Now when we restarted jboss, now "second.ear" works fine. and we get the "no username found in principals" error for the xyz.ear.

We googled and identified that the client login module of Jboss caches user credentials and use it on subsequent invokations of EJB. And both of our deployments use the client login module.

Code snippet from login.conf for one application is below:

-- login-conf.xml start here..
<application-policy name="first">
<authentication>
<login-module code="org.jboss.security.ClientLoginModule" flag="required" />
<login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
<module-option name="dsJndiName">
java:/firstDS
</module-option>
<module-option name="principalsQuery">
SELECT iu.hash FROM users iu WHERE IsActive=1 and iu.EmailID=?
</module-option>
<module-option name="rolesQuery">
<!-- query trimmed here.. assume it returns a valid set of roles -->
SELECT baa.Roles,'Roles' FROM OurRoles baa
WHERE baa.IsActive=1 and baa.EmailID=?
</module-option>
</login-module>
</authentication>
</application-policy>
-- login-conf.xml ends here..

Configuration code snippet for the other application will be similar to the one above with changes in dsName and policy name.

Is it like client-login is hard-coded in jboss and only one instance of application (first-come-first-served logic) applied ?

Can someone let us know if there are any pointers for us to proceed ?

Thanks in advance
16 years ago
We are running a struts application in Tomcat container of JBoss 4.0.3 SP1. We had the same problem. Here is how we fixed it...
# Copied hibernate.cfg.xml to the JBoss/bin directory.
# Added "." to my classpath.
# Called startup batch file (run.bat) from JBoss/bin directory.

Now, this error is not thrown. It works fine...