[Clustering/JBoss] - Re: JNDI vs. HA-JNDI lookups
by Marlig
Thanks for your replies. I guess I'm seeing the behaviour that Brian described, where my client gets the EJB-proxy, and since the EJBs are configured as clustered, all calls to that EJBs are load-balanced.
I just remembered that we had to manually set the invoker-proxy-bindings to support some clients that run on older JDK versions:
| <invoker-proxy-bindings>
| <invoker-proxy-binding>
| <name>clustered-retry-stateless-rmi-invoker</name>
| <invoker-mbean>jboss:service=invoker,type=jrmpha</invoker-mbean>
| <proxy-factory>org.jboss.proxy.ejb.ProxyFactoryHA</proxy-factory>
| <proxy-factory-config>
| <client-interceptors>
| <home>
| <interceptor>org.jboss.proxy.ejb.HomeInterceptor</interceptor>
| <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
| <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
| <interceptor>org.jboss.proxy.ejb.RetryInterceptor</interceptor>
| <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
| </home>
| <bean>
| <interceptor>org.jboss.proxy.ejb.StatelessSessionInterceptor</interceptor>
| <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
| <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
| <interceptor>org.jboss.proxy.ejb.RetryInterceptor</interceptor>
| <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
| </bean>
| </client-interceptors>
| </proxy-factory-config>
| </invoker-proxy-binding>
|
Maybe this forces the load-balancing, no matter which port I connect to??
Otherwise, how could I call my EJBs and make sure the call only goes to one of the nodes?
Thanks
Martin
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024569#4024569
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024569
19Â years, 1Â month
[JBossWS] - JbossWS 1.2.0
by matienzar
Hello,
With 1.0.4 release, i've a hibernate handler to begiun a transaction and to commit it. With this new realese, the handler is not threadsafe, and when I need to commit the transaction, it's null. I'd defined the handler (with 1.0.4) in standard-jaxrpc-endpoint-config.xml, but with this new realse i've to define it in standard-jaxws-endpoint-config.xml.
The code of the handler is:
public class HibernateWS extends GenericSOAPHandler {
UserTransaction _tx = null;
@Override
public boolean handleFault(MessageContext arg0) {
try {
_tx.rollback();
} catch (Exception e) {
Log.error("No se ha podido hacer el rollback", e);
throw new RuntimeException(e);
}
return super.handleFault(arg0);
}
protected boolean handleInbound(MessageContext msgContext) {
try {
HibernateUtil.openSession();
_tx = (UserTransaction) new InitialContext()
.lookup("java:comp/UserTransaction");
_tx.begin();
} catch (Exception e) {
Log.error("Cogiendo la transacción.", e);
}
return true;
}
protected boolean handleOutbound(MessageContext msgContext) {
try {
_tx.commit();
} catch (Exception e) {
Log.error("Haciendo el commit", e);
try {
_tx.rollback();
} catch (Exception e2) {
Log.error("Haciendo el rollback", e2);
}
throw new RuntimeException(e);
}
return true;
}
}
And the config-handler:
<endpoint-config>
<config-name>Handler hibernate gnomo</config-name>
<pre-handler-chains>
<javaee:handler-chain>
<javaee:protocol-bindings>##SOAP11_HTTP</javaee:protocol-bindings>
<javaee:handler>
<javaee:handler-name>WSHibernateHandlerInbound</javaee:handler-name>
<javaee:handler-class>org.muvale.utilidades.handlers.HibernateWS</javaee:handler-class>
</javaee:handler>
</javaee:handler-chain>
</pre-handler-chains>
</endpoint-config>
A lot of thanks,
Marcial
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024562#4024562
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024562
19Â years, 1Â month
[JBoss Seam] - Re: Seam security with JAAS config
by pdpantages
Yes, you are correct; there is a mechanism protecting the calls. Up until now, I
had been using the FORM method to authenticate with a login
servlet. Once authenticated, this authorization mechanism works properly.
I wanted to add and use the Seam Identity to do role-based page-level
authorzation, and for conditional rendering in my facelets, while
keeping the old authorization mechanism for methods.
I though that the JAAS authentication would behave the same way, if I specified
a jass-config-name in components.xml.
I.e., like the call I see in FormAuthenticator:
| ...
| principal = context.getRealm().authenticate(username,password);
|
It doesn't appear that the Identity authenticates the way
FormAuthenticator did. I guess this is design intent.
Since it doesn't, I though I could make this call myself, in an
"authenticate-method", something like:
| public class Authenticator {
| public boolean authenticate() {
| ....
| Realm realm = ???
| p = realm.authenticate(identity.getUsername(),identity.getPassword());
| ...
| return true;
| }
|
Then, if it was OK, I would populate the identity with the user's roles return true.
....But I can't figure out how the get ahold of the/a "Realm" instance. I see that the
FormAuthenticator gets it from the context, which comes from the request.
Is this workable, or am I missing something obvious....? I am a bit of
a novice with JAAS & have to admit it is a bit confusing at times.
A dumpstack for My old FORM method authentication. ( I looked at these sources
to see how a successful authentication is/was done. )
| at java.lang.Thread.dumpStack(Thread.java:1158)
| at centina.sa.server.security.SecurityManager.completeLogin(SecurityManager.java:507)
| at centina.sa.server.security.SecurityManagerLoginModule.commit(SecurityManagerLoginModule.java:181)
| 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:580) Above called at (579)
| at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:601)
| at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:535)
| at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:344)
| at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.authenticate(JBossSecurityMgrRealm.java:491)
| at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:257)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:416)
| 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)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024561#4024561
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024561
19Â years, 1Â month