Folks,
I've been playing with Jo! the webserver and it is very stable under
Phoenix configuration. To remind everyone Jo has a service of :-
public void deployWAR(String hostName, String name, String ctxPath,
String warUrl) throws Exception;
public void undeployWAR(String hostName,String name) throws Exception;
I don't think it is perfect that each throws Exception. Perhaps
JoException might be more usable. I think what we need is an
interface/impl separation of the current block We'd end up with two
blocks one for the service that depending applications would compile
against and include in their SAR. The other would contain the hidden
impl. and only be in Hendrik's avalon-jo.sar. I've emailed Hendrik to
ask for these...
What is the feeling about the inter-sar communication. Clearly we need
a lookup stage before the service can be used just like normal.
Question is should it be part of the existing API :-
public void compose( final ComponentManager componentManager ) throws
ComponentException {
mMyService = (MyService) componentManager.lookup( MyService.ROLE );
mJoService = (Jo) coponentManager.lookup( Jo.ROLE );
}
Or a separate API? :-
public void compose( final ComponentManager componentManager ) throws
ComponentException {
mMyService = (MyService) componentManager.lookup( MyService.ROLE );
}
public void compose( final CrossApplicationComponentManager
componentManager ) throws ComponentException {
mMyService = (MyService) componentManager.lookup( MyService.ROLE );
}
It is important because we might need to juggle the needs of Phoenix
which might like to do all lifecycles methods against each sar in turn
and the assembler who might like to choose whether a particular
application depends on a block that the sar contains or another in an
alternate sar that is also deployed.
Regards,
- Paul H
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
