jQuery in Action, 3rd edition
The moose likes JBoss/WildFly and the fly likes glassfish to JBoss communication through RMI Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » JBoss/WildFly
Bookmark "glassfish to JBoss communication through RMI" Watch "glassfish to JBoss communication through RMI" New topic

glassfish to JBoss communication through RMI

Karl Krasnowsky
Ranch Hand

Joined: Jan 16, 2009
Posts: 97
Not sure if this is the proper forum for this question, but would seem possible.
We currently have a web application deployed to a Glassfish server. We are needing to communicate to an application deployed to a JBoss server at various points during our applications lifecycle.
In order to establish the connection to the JBoss server it is necessary to set environment naming properties in our environment while the call is made, and then swapping them back out to the original Glassfish naming properties when complete so local calls in the server can resolve.

So to make the call we save off the current set of GF of properties, and make a call to set them to the JBoss system like this:

then make the call, and then reset to GF properties after completion. The problem with this is while the call is being made (and there could be many in succession so there is no way to know how long or how often such a connection will be used) no local calls from the GF appserver is possible, for example a datasource defined in the JNDI service through GF.
It would appear that to use this system as is, it would be necessary to synchronize on all methods that may make a local call while a remote JBoss connection is in progress, and the opposite when local calls are in progress. First I'm not sure if this even possible, and 2nd this gets exponentially more complicated as multiple users hit our web application(s).
My take on this, I have a few options.
  • Try do do what I stated above (don't think it's possible)
  • Deploy my web application to the same JBoss server as the service I'm calling (don't know now whether this is possible)
  • Make my application a standard client application to do away with the possibility with other users stomping on my environment.

  • Maybe there's another solution that I'm not considering? Ideally I'd like to keep the current configuration as it is to save time reworking (it wasn't my idea to set it up this way, I inherited this when contracted out to help them out of this mess), but if my hunch is correct I don't see how it can be maintained properly and scalability would be a huge problem.

    any thoughts?

    [SCJP 6]
    [SCBCD in process]
    Jaikiran Pai

    Joined: Jul 20, 2005
    Posts: 10441

    //need to set the naming properties so JBoss rules for a while
    private Properties getConnectProps(Properties props) {

    Why do yo want to have a single method which returns the properties for both JBoss AS and Glassfish?

    Wherever you require to communicate with JBoss AS, you could just do (just an example - there are other ways of doing it too):

    and wherever you want to communicate with Glassfish, you can do:

    [My Blog] [JavaRanch Journal]
    Karl Krasnowsky
    Ranch Hand

    Joined: Jan 16, 2009
    Posts: 97
    That is what I'm doing. Problem is (I believe) is this...
    This context switching is performed in a library that a client will be interfacing with, this client in this context is a web application which (obviously) possibly multiple users can be using. If I go changing the initial context to one state at the same time another user of the client application is wanting (expecting) to use the "real" initial state, then it will fail.
    Since the controlling of this state isn't in the client's hands directly there stands to be the real possibility that, yes, a method could be authored that mixes the two contexts up, and should be.

    I agree. Here's the link: http://aspose.com/file-tools
    subject: glassfish to JBoss communication through RMI
    jQuery in Action, 3rd edition