Hi there;
and first off, thanks a load for your comments, much appreciated and rather
helpful indeed. :)
glassfish_at_javadesktop.org schrieb:
> The first thing you need to do to enable your loose coupling is to really
> lock down your interfaces and their granularity. If you change the
> interface at all, both servers and clients will need to be redeployed. I
> believe this is true even with web services, it's definitely true with
> Remote EJBs.
Okay, that's fine so far. We do deal interfaces as a rather static thing
indeed, however given different people working on different EJB modules,
having one of them redeployed if its internals changed without messing with
the rest of the system seems desirable...
> Are you doing WAR -> EJB? or EJB -> EJB?
Generally both, but at the moment it's up to EJB->EJB.
> I believe that EJB references (ala @EJB) can be cached, and that may well
> be what is happening for you. So, one thing that you can do to mitigate
> that problem is rely on your own lookup mechanism rather than @EJB. You
> can cache them in a singleton, and then when you do a lookup for a new
> instance, you can add a "ping" do nothing method, check that, and if it
> fails just look it up again to get a "new" one.
[...]
> So, those are some ideas on how you can get around the Remote EJB
> connection issues.
Following your advice I wrapped my Remote EJB reference in a local getter
checking first whether or not the reference is still here, something like that:
[...]
if (null == service) {
try {
InitialContext ic = new InitialContext();
this.service = (DocumentServiceRemote)
ic.lookup("java:comp/env/DocumentService");
logger.log(Level.INFO, "DocumentService found, attached.");
} catch (NamingException ex) {
logger.log(Level.SEVERE, "documentService <null>; not
resolved yet: ", ex);
}
}
[...]
Oddly enough it just worked exactly once after redeploying the modules in
the "correct order"; by now, no matter how I get them deployed, I regularly
end up with
[...]
javax.naming.NameNotFoundException: No object bound to name
java:comp/env/DocumentService
[...]
... whereas it seems deploying the relevant module, the object is correctly
bound to the JNDI name defined:
[#|2008-10-17T11:25:02.100+0200|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=23;_ThreadName=httpWorkerThread-4848-3;|
**RemoteBusinessJndiName: DocumentService; remoteBusIntf:
planconnect.core.docaccess.services.DocumentServiceRemote|#]
Hmmm... I'm not too deep into JNDI so far; is this a "general basic problem"
I just am not aware of, or is there something else I should pay attention to
here?
Thanks in advance and best,
Kristian
--
Kristian Rink
cell : +49 176 2447 2771
business: http://www.planconnect.de
personal: http://pictorial.zimmer428.net
"we command the system. calling all recievers.
we are noisy people for a better living".
(covenant - "monochrome")