[Security & JAAS/JBoss] - How to marshall principal/credentials from client login to s
by daviddpark
I am attempting to implement java security in an application that is architected as follows:
We have a web tier running in a jboss instance. This web tier has no datasources available to it. The only way it has access to data is through a business tier, a set of applications running in another jboss instance. For simplicity, we will refer to the two instances as web-1 and service-1.
To complicate things further in our system, we require three bits of information to uniquely identify a user. The loginid, the password and the domain. In our system, we enforce unique loginids in each domain, but they all live relatively harmoniously in the same database tables. The loginid in and of itself will not necessarily be unique, but coupled with the domain, we could have a primary key, although the real primary key of the user table is a userid column, which is what we REALLY want as our principal once we get into the business tier. (We allow our customers to choose their own loginid, but the userid is system generated)
Ok, so having read Chapter 8 of the admin guide 23 times, I understand that there will be two parts of the JAAS login process.
I first attempted to use the ClientLoginModule that JBoss provides to marshall the login credentials from the web layer to the service layer. We are instantiating the LoginContext with "other", which is mapped to ClientLoginModule in login-config.xml. (The service layer ejbs are all part of the same security-domain, which we'll refer to as "jwdomain")
Here is my login-config.xml snippet:
| <application-policy name="jwdomain">
| <authentication>
| <login-module code = "my.package.MyLoginModule" flag = "required">
| <module-option name="unauthenticatedIdentity">guest</module-option>
| <module-option name="password-stacking">useFirstPass</module-option>
| <module-option name="multi-threaded">true</module-option>
| </login-module>
| <login-module code="org.jboss.security.ClientLoginModule" flag="required">
| <module-option name="password-stacking">useFirstPass</module-option>
| <module-option name="multi-threaded">true</module-option>
| </login-module>
| </authentication>
| </application-policy>
| <application-policy name = "other">
| <authentication>
| <login-module code="org.jboss.security.ClientLoginModule" flag="required">
| <module-option name="unauthenticatedIdentity">guest</module-option>
| <module-option name="multi-threaded">true</module-option>
| </login-module>
| </authentication>
| </application-policy>
|
And a snippet from my login action in the web layer:
(Since unauthenticated I can't yet look up the userid, I get creative and construct a unique "username" from loginid, a string of text that we hope nobody ever uses as a loginid or domain, and the actual domain strings.)
ProcessLoginAction.java snippet:
| CallbackHandler cbHandler = new UsernamePasswordHandler
| (new StringBuffer(loginid).append("UNIQUETOKEN").append(domain).toString(), password.toCharArray());
| LoginContext loginContext;
| try {
| loginContext = new LoginContext("other",cbHandler);
| loginContext.login();
| } catch (LoginException e) {
| throw new ApplicationException(e);
| }
|
Stepping through the executing code, things seem to progress nicely. My ProcessLoginAction class instantiates the "other" LoginContext, and by the time the commit() method is called, we can see that the Subject is populated with Principal and Credentials, as expected from what is passed in via the CallbackHandler.
After the LoginContext.login() succeeds, we invoke the create() methot on an EJB that has a) been set to unchecked method-permission and b) security-domain of "jwdomain" (See jboss.xml and ejb-jar.xml snippets below) and the server side of the JAAS login proceeds as planned, as we step through MyLoginModule. By the time we've gone through the login() and commit() method, we've done actual authentication on the credentials marshalled to the service login invocation via the client side login. So far, so good.
MyLoginModule.java:
| public class MyLoginModule extends AbstractServerLoginModule {
| private Principal csIdentity;
| public boolean login() throws LoginException {
| String userid = null;
| Callback[] callbacks = new Callback[2];
| callbacks[0] = new NameCallback("loginid+domain should have been provided by web layer");
| callbacks[1] = new PasswordCallback("Password should have been provided by web layer",false);
| String ltd = null;
| String password = null;
| try {
| callbackHandler.handle(callbacks);
| ltd = ((NameCallback)callbacks[0]).getName();
| if (((PasswordCallback)callbacks[1]).getPassword() != null) {
| password = new String(((PasswordCallback)callbacks[1]).getPassword());
| }
| } catch (Exception e) {
| throw new LoginException(e.getMessage());
| }
| try {
| if (ltd != null && password != null) {
| String loginid = null;
| String domain = null;
| String token = "UNIQUETOKEN";
| String[] loginiddomain = ltd.split(token);
| if ( loginiddomain.length == 2 ) {
| loginid = loginiddomain[0];
| domain = loginiddomain[1];
| }
| userid = getUserid(loginid,domain);
| if(userid == null ) {
| throw new LoginException("Unable to determine unique identifier for "+loginid+"/"+assoc+".");
| }
| String expectedPassword = getPassword(userid);
| if(password != null && !password.equals(expectedPassword)) {
| throw new LoginException("Passwords do not match.");
| }
| csIdentity = createIdentity(userid);
| loginOk = true;
| }
| } catch (Exception e) {
| throw new LoginException(e.getMessage());
| }
| return super.login();
| }
| protected String getUserid(String loginid, String association) {
| //implementation details not needed
| }
| protected String getPassword(String userid) {
| //implementation details not needed
| }
| public Principal getIdentity() {
| return csIdentity;
| }
| protected Group[] getRoleSets() throws LoginException {
| Group roles = new SimpleGroup("Roles");
| //actual implementation to follow after successful test
| Principal role = new SimplePrincipal("foorole");
| roles.addMember(csIdentity);
| roles.addMember(role);
| Group cp = new SimpleGroup("CallerPrincipal");
| cp.addMember(csIdentity);
| return new Group[]{roles,cp};
| }
| }
|
The server side login() succeeds, stepping through the above code shows success, but the subsequent EJB create() fails with:
| Insufficient method permissions, principal=myLoginidUNIQUETOKENmyDomain, ejbName=AccountManager, method=create, interface=HOME, requiredRoles=[], principalRoles=null
|
Now this failure happened while the ProcessLoginAction attempted to lookup and call a method on an EJB in the service layer, secured by the "jwdomain" as follows:
| <jboss>
| <security-domain>java:/jaas/jwdomain</security-domain>
| <enterprise-beans>
| <session>
| <ejb-name>AccountManager</ejb-name>
| <jndi-name>AccountManagerManager</jndi-name>
| <local-jndi-name>AccountManagerManagerLocal</local-jndi-name>
| </session>
| ...
| </jboss>
|
But ALL of my session bean methods are flagged as unchecked! (for now)
| <ejb-jar >
|
| <description>AccountManager to retrieve info from service tier</description>
| <enterprise-beans>
| <session >
| <ejb-name>AccountManager</ejb-name>
| ...
| <session-type>Stateless</session-type>
| <transaction-type>Bean</transaction-type>
| <security-identity>
| <use-caller-identity />
| </security-identity>
| </session>
| ...
| <method-permission >
| <unchecked/>
| <method >
| <ejb-name>AccountManager</ejb-name>
| <method-intf>Remote</method-intf>
| <method-name>create</method-name>
| <method-params>
| </method-params>
| </method>
| </method-permission>
| ...
| </ejb-jar >
|
So, I thought that maybe there's something awry between requiredRoles=[] and principalRoles=null.... that maybe AT LEAST ONE role is expected. So I try to force this to happen... I try it two ways:
The first way, I changed my login-config.xml as follows:
| <application-policy name = "other">
| <authentication>
| <login-module code="org.jboss.security.auth.spi.RunAsLoginModule" flag="required">
| <module-option name="roleName">foo-admin</module-option>
| </login-module>
| <login-module code="org.jboss.security.ClientLoginModule" flag="required">
| <module-option name="unauthenticatedIdentity">guest</module-option>
| <module-option name="multi-threaded">true</module-option>
| </login-module>
| </authentication>
| </application-policy>
|
That didn't help me at all. So, I changed ClientLoginModule to a custom client side login module that extends UsernamePasswordLoginModule so that I could specify a dummy role via the getRoleSets() method, overriding the validatePasswords() method as well so that it would always return true (after all, it's a client side login module that doesn't _really_ provide any meaningful authentication... the sole purpose of this login module is to marshall the Subject Principal and credentials to the service layer where the real business is transacted. So, I implement a getRoleSets() method as follows:
| public class MyClientLoginModule extends UsernamePasswordLoginModule {
| String password = "";
| public String getUsersPassword() { return password; }
| protected boolean validatePassword(String inputPassword, String expectedPassword) { return true; }
| protected Group[] getRoleSets() throws LoginException {
| Principal identity = super.getIdentity();
| Group roles = new SimpleGroup("Roles");
| Principal role = new SimplePrincipal("foorole");
| roles.addMember(identity);
| roles.addMember(role);
| return new Group[]{roles};
| }
| }
|
Straight up, right? When I execute this code, it all _looks_ good, but still no dice, same error. Maybe I'm missing something in the way Subject<->Principal<->Principals<->Groups<->Roles all _really_ work together. It seems that if I can just get a bogus role associated with my client side Subject then maybe the EJB create() would work?
Then again, maybe I'm just barking up the wrong tree, because what I really want for my principal is not that bastardized concatenization of loginid, unique token and domain, but the actual system primary key user id, that which the server side MyLoginModule identity identifies once a LoginModule is executing in a place where the customer provided loginid/domain/password can be properly authenticated and turned into a proper Principal (rather CallerPrincipal, what I am ultimately after)
If anything glaringly obvious jumps off the page, please enlgihten me, as I simply cannot see the forest through the trees.
Thanks in advance,
-david
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972803#3972803
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972803
19 years, 7 months
[JBoss jBPM] - Issue with jBPM and EJB3 RC9 FD?
by scotto
Hello.
Since upgrading from EJB3 RC8 to RC9 on JBossAS4.0.4.GA, I am getting a new exception with jBPM in code that was previously working fine (using both jBPM 3.1.1 and jBPM 3.1.2).
The exception I am getting is unusual (full exception trace shown at the end of this post):
anonymous wrote :
| Exception: javax.ejb.EJBTransactionRolledbackException: javax.persistence.PersistenceException: org.hibernate.HibernateException: instance not of expected entity type: org.jbpm.graph.def.Node_$$_javassist_118 is not a: org.jbpm.graph.def.Node
|
This makes me think there could be an issue with jBPM and the new version of Hibernate used in EJB3 RC9?
The code in question is a @Stateless session bean method (with an injected @PersistenceContext EntityManager) that uses a JbpmContext to create and start a jBPM workflow process.
This code is slightly unconventional, in that I am explicitly sharing the injected EntityManager's hibernate session with the JbpmContext, so as to avoid creating a nested transaction. The code excerpt for this from the SLSB is as follows:
// Injected EntityManager
| @PersistenceContext protected EntityManager em;
| ....
| public long createProcess(...) {
| // Share the EntityManager's hibernate session with jBPM
| JbpmContext jbpmContext = JbpmConfiguration.getInstance().createJbpmContext();
| HibernateEntityManager hem = (HibernateEntityManager)em.getDelegate();
| jbpmContext.setSession( hem.getSession() );
| try {
| ProcessDefinition processDefinition = jbpmContext.getGraphSession().findLatestProcessDefinition(processDefinitionName);
| ProcessInstance processInstance = new ProcessInstance(processDefinition);
| ...
| // Initialise process context variables
| ...
| jbpmContext.save(processInstance);
| return processInstance.getId();
| } catch( ... ) { ... }
| finally {
| jbpmContext.close();
| }
| }
I have put all the jBPM Hibernate mapping file definitions in my EJB3 persistence.xml file, and jBPM is deployed as part of my application .ear file. This configuration has been working well for months with EJB3 RC8 and earlier.
The other part of the error which is confusing me is the nested "EntityManager must be access within a transaction" exception, which I think must be a red-herring side-effect of the initial "instance not of expected entity type" exception, as there is definitely a transaction in progress when I pass the hibernate session to the JbpmContext (as it is SLSB method code which creates the JbpmContext).
Does anyone have any idea why I'm now getting this failure when the only change is an upgrade from EJB3 RC8 to RC9?
Here is a full trace of the exception:
anonymous wrote :
| 2006-09-20 11:03:40,171 203125 ERROR [com.vieo.ccs.model.process.impl.WorkflowProcessFactoryBean] (pool-3-thread-2:) Exception: javax.ejb.EJBTransactionRolledbackException: javax.persistence.PersistenceException: org.hibernate.HibernateException: instance not of expected entity type: org.jbpm.graph.def.Node_$$_javassist_118 is not a: org.jbpm.graph.def.Node
| 2006-09-20 11:03:40,171 203125 ERROR [com.vieo.ccs.model.topology.commands.StartProcessCommand] (pool-3-thread-2:) Error initialising process: ILU Assistance Call : com.vieo.ccs.model.topology.WorkflowException: javax.ejb.EJBTransactionRolledbackException: javax.persistence.PersistenceException: org.hibernate.HibernateException: instance not of expected entity type: org.jbpm.graph.def.Node_$$_javassist_118 is not a: org.jbpm.graph.def.Node
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) Exception in thread "pool-3-thread-2"
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) javax.ejb.EJBException: javax.persistence.TransactionRequiredException: EntityManager must be access within a transaction
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:275)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:131)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:211)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:79)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at $Proxy220.processDeviceEvent(Unknown Source)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at com.vieo.ccs.server.handlers.GatewayMessageHandler.process(GatewayMessageHandler.java:48)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at com.vieo.ccs.server.handlers.MessageHandlerFactory.processMessage(MessageHandlerFactory.java:54)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at com.vieo.ccs.server.AMQGatewayServerThread.run(AMQGatewayServerThread.java:61)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
| 2006-09-20 11:03:40,187 203141 ERROR [STDERR] (pool-3-thread-2:) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
| 2006-09-20 11:03:40,218 203172 ERROR [STDERR] (pool-3-thread-2:) at java.lang.Thread.run(Thread.java:595)
| 2006-09-20 11:03:40,218 203172 ERROR [STDERR] (pool-3-thread-2:) Caused by: javax.persistence.TransactionRequiredException: EntityManager must be access within a transaction
| 2006-09-20 11:03:40,218 203172 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.ejb3.entity.ManagedEntityManagerFactory.verifyInTx(ManagedEntityManagerFactory.java:149)
| 2006-09-20 11:03:40,218 203172 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.ejb3.entity.TransactionScopedEntityManager.merge(TransactionScopedEntityManager.java:180)
| 2006-09-20 11:03:40,218 203172 ERROR [STDERR] (pool-3-thread-2:) at com.vieo.ccs.model.topology.impl.GatewayConnectorBean.processDeviceEvent(GatewayConnectorBean.java:121)
| 2006-09-20 11:03:40,218 203172 ERROR [STDERR] (pool-3-thread-2:) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| 2006-09-20 11:03:40,218 203172 ERROR [STDERR] (pool-3-thread-2:) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| 2006-09-20 11:03:40,218 203172 ERROR [STDERR] (pool-3-thread-2:) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| 2006-09-20 11:03:40,218 203172 ERROR [STDERR] (pool-3-thread-2:) at java.lang.reflect.Method.invoke(Method.java:585)
| 2006-09-20 11:03:40,218 203172 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
| 2006-09-20 11:03:40,218 203172 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
| 2006-09-20 11:03:40,218 203172 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.seam.ejb.SeamInterceptor.aroundInvoke(SeamInterceptor.java:40)
| 2006-09-20 11:03:40,218 203172 ERROR [STDERR] (pool-3-thread-2:) at sun.reflect.GeneratedMethodAccessor151.invoke(Unknown Source)
| 2006-09-20 11:03:40,218 203172 ERROR [STDERR] (pool-3-thread-2:) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| 2006-09-20 11:03:40,250 203204 ERROR [STDERR] (pool-3-thread-2:) at java.lang.reflect.Method.invoke(Method.java:585)
| 2006-09-20 11:03:40,250 203204 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:118)
| 2006-09-20 11:03:40,250 203204 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
| 2006-09-20 11:03:40,250 203204 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| 2006-09-20 11:03:40,250 203204 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
| 2006-09-20 11:03:40,250 203204 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| 2006-09-20 11:03:40,250 203204 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
| 2006-09-20 11:03:40,250 203204 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| 2006-09-20 11:03:40,250 203204 ERROR [STDERR] (pool-3-thread-2:) at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
| 2006-09-20 11:03:40,250 203204 ERROR [STDERR] (pool-3-thread-2:) ... 22 more
|
Thanks!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972801#3972801
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972801
19 years, 7 months
[JBoss Portal] - a non technical thing for Roy and/or Julien
by jewhit
Guys -
has JBoss ever really featured Portal during one of their On the Road "tours" or something similar.
if not, they should. i went to the presentation that was in Philadelphia today... probably the best darned public relations seminar i have been to for quite some time... and i have been to many. they did a bang up job in promoting ON. matter of fact, they did it in such a fashion where you didnt even realize that they were promoting it.
I think it is general consensus that all portal technology is "too new." strangely enough, in a few of the conversations that i had today with some of JBoss' customers (and one or two that arent yet, but probably will be) portal came up in discussion... some were positive, some were negative... not necessarily negative about Jboss portal, but portals in general.
There is a great amount of confusion out there. Many developers, even highly seasoned ones, have a tough time getting off of the ground and using portal to their best of abilities, whether due to lack of complete start to finish how-to's or lack of time to master a new technology in a corporate environment. It is all about $$$. Corporate management in a majority of cases cannot relate to the true value of a portal framework... the problem that i personally am having is dealing with "whats the big deal, its just a web site." what isnt understood is that there is sometimes a range of complexities involved in utilizing this type of technology, and to compound the issue, "newness" doesnt help. The classic answer that we get from senior management is " go buy a book." Good luck finding one, or at least a decent one, on java portals / portlets.
i kinda got a bit sidetracked there, but you get the gist of it. in some capacity, word has to spread on what the technology is, what it can do, and how to do it. JBoss has pioneered a few things in its time, and from what i can gather none of their efforts have been unsuccessful. would it be appropriate for them to "sow the fields, and see what sprouts up?" you have a better than most product. how can it be pushed out and accepted at a greater level ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972798#3972798
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972798
19 years, 7 months
[Remoting] - Re: Failed to accept socket connection
by buttmanizer
BTW, on the client program, i got this error:
| javax.naming.NamingException: Could not dereference object [Root exception is org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection.]
| at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1150)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:705)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
| at javax.naming.InitialContext.lookup(InitialContext.java:351)
| at com.medsoft.util.DataLoader.addRoles(DataLoader.java:51)
| at com.medsoft.util.DataLoader.<init>(DataLoader.java:40)
| at com.medsoft.util.DataLoader.main(DataLoader.java:109)
| Caused by: org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection.
| at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:267)
| at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
| at org.jboss.remoting.Client.invoke(Client.java:525)
| at org.jboss.remoting.Client.invoke(Client.java:488)
| at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:48)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:61)
| at $Proxy0.createProxy(Unknown Source)
| at org.jboss.ejb3.JndiProxyFactory.getObjectInstance(JndiProxyFactory.java:52)
| at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
| at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1125)
| at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1142)
| ... 6 more
| Caused by: java.lang.reflect.InvocationTargetException
| at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
| at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
| at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
| at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
| at org.jboss.remoting.transport.socket.SocketClientInvoker.createClientSocket(SocketClientInvoker.java:518)
| at org.jboss.remoting.transport.socket.SocketClientInvoker.getConnection(SocketClientInvoker.java:485)
| at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:263)
| ... 19 more
| Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
| at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:742)
| at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1030)
| at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:678)
| at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
| at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
| at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
| at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
| at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2222)
| at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2235)
| at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2703)
| at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:760)
| at java.io.ObjectInputStream.<init>(ObjectInputStream.java:278)
| at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(ObjectInputStreamWithClassLoader.java:73)
| at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:52)
| at org.jboss.remoting.transport.socket.ClientSocketWrapper.createInputStream(ClientSocketWrapper.java:83)
| at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:76)
| at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:54)
| ... 26 more
| Caused by: java.io.EOFException: SSL peer shut down incorrectly
| at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:333)
| at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:723)
| ... 42 more
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972795#3972795
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972795
19 years, 7 months