Peter,
>>void deployWAR(String key, File warFile) throws WARDeploymentException;
>> void deployWAR(String key, URL warFile) throws WARDeploymentException;
>> void deployWAR(String key, InputStream warFile) throws
>>WARDeploymentException ;
>> void deployWAR(String key, ClassLoader warFile) throws
>>WARDeploymentException;
>> void unDeployWAR(String key) ..;
>>
>
>Sounds good except I wouldn't make the interface extend anything.
>
Not extend "Service"? OK...
>I guess the
>problem is that without a real-life test-case I don't think we are going to
>have an easy time defining a generic interface. For instance the in-JVM EJB
>container has a fairly incestuos relationship with servlet container and they
>have to share all sorts of resources (ie ClassLoader hierarchy is very
>specific as in shared JVM resources etc).
>
Incestuous - yes agree. Weblogic does all sorts of sharing beatween
beans and webserver. It shortcircuits (by default) RMI internally.
However, the plain contract with the webserver is one where the WAR
file is self contained and does use true RMI to interoperate with the
beans server. Perhaps that resource sharing version is one extension more :
interface ServletHTTPServer extends HTTPServer {...}
interface WARFileHTTPServer extends ServletHTTPServer {...}
interface ResourceSharingWARFileHTTPServer extends WARFileHTTPServer {...}
>It may be a good idea to have a bash at it but I would mark it as possibly
>changing in future or highly volatile or whatever - at least until we see
>some reali-life testing. Thoughts?
>
Yes agree. Refactor when necessary and based on merit.
This, if we do it, pushes down the road of a) standardized APIs for
/regular/ server components. Why? well, it a true multi service Avalon
machine we'd not have the http server as a block in a sar that also
conatined the ejb server ..... multiple other sars might need it (http
server) being accessible too. Can you remember all that deep thinking
we did with Fede about "promotion of interfaces" at Xmas (refer Fred &
Wilma demo classloaders), well all that's unecessary if you have a
centralized place for interfaces (for regular comps).
So in summary, in the assembly.xml, a block could depend on another
service that was outside of it's own sar file. I think that's the major
change here. That we're specifying regular services in Avalon
(irrespective of implementation) is incidental.
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
