Gidday Chuck,
Firstly are you developing 1.0 or 1.1 based beans ?
Are the servers on the individual boxes the same as the server on the main
box, I will assume so for the purposes of this discussion.
For 1.0 EJB's to be location independant you can (must) make extensive use of
the properties fields in the deployment descriptor. You can then make run time
queeries of the deployment properties and build your jndi url this way.
E.g.
from one of the methods from inside of your bean on the development machine
you can do something like this :-
private void callBeanInOtherContainer () {
Context newContext = new InitialContext(props);
NewHome newhome = PortableRemoteObject.narrow(
newContext.lookup(newBean URL),
NewHome.class);
NewBean newbean = newhome.create();
}
You set the props variable in the SetEntityContext() or SetSessionContext()
methods of the bean like this :-
Properties env = ctx.getEnvironment()
Finally you need to put the info in the Deployment Descriptor of the bean
e.g.
(environmentProperties
; Application-specific environment properties
// JNDI Vars required
java.naming.security.principal system
java.naming.security.credentials ejbproject
java.naming.factory.initial weblogic.jndi.T3InitialContextFactory
newBeanURL newBean.NewBeanHome ; This is the JNDI of your
; bean in the remote or
; central container
); end environmentProperties
This should enable you to develop beans on the remote machines which make
calls to the central EJB server. Once again I have assumed 1.0 development.
EJB 1.1 uses XML to define the remote resources. See section 14.3.1 of the
EJB 1.1 spec for an example of how to do this with EJB 1.1 based beans.
Oh BTW: once you have the initial Context for the namespace of the remote
container you can use JNDI lookup and list to search the namespace. We found
this to work pretty well in most containers (with a couple of exceptions) once
again EJB 1.1 makes this area much cleaner.
HTH and makes at least some sense.
Tom Daly (Sun)
PS: The above code is example ..not tested please treat it as such :-)
> Hello,
>
> If you have seen this message before, please ignore.
>
> Here is a problem regarding to EJB development, and I would like to know
> how other people solve it.
>
> We are currently developing a reasonably large system with WebLogic EJB
> Server with dozens of developers. We plan to have each developer run
> their own EJB Server on their PC for developing their own EJBean. Once
> the EJBean is developed, it is moved/deployed to a EJB Server running on
> a larger Unix box to be shared by all developers. Then developers work
> on new EJBeans which depends on those EJBeans on the Unix server.
>
> This present a problem: How do you concurrently access EJBeans in two
> EJB
> server with location transparency? We don't want to hard-code any
> location
> info because all EJBeans will evnetually end up on the Unix Server.
>
> My understanding is that EJB Homes are published in JNDI by containers
> into
> individual EJB servers. If we can make the contents of Unix Server's
> JNDI
> naming space available on each developer's PC's EJB server / JNDI naming
> system, then the problem is solved. At present, we are not planning to
> use WebLogic clustering approach.
>
> We are writing a JNDI application to do it ourself. I am thinking along
> the line
>
> 1) get a JNDI Reference of the EJB Home on Unix Server,
> 2) add that Reference/LinkRef into my PC's JNDI.
>
> I have no success yet - I could not find a way to get the JNDI Reference
> in
> step 1) after reading all the specs and tutorials (with some
> confusions).
> It seems to me that Reference is handled by Service Provider and not
> for "client" programming use.
>
> So I wonder
> - is our approach correct?
> - If no, what's correct approach?
> - If yes, How do I get the Reference?
> - Also, how an EJBean is published in JNDI naming system? I mean, does
> Container just bind the Home class to the name, or a JNDI Reference to
> the Home class is bound?
>
> - JNDI also mentioned URL for constructing RefAddr/Reference. Where
> could I
> get this URL naming convention for EJB servers?
>
> Thanks in advance,
>
> Chuck Zheng
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
