On Tue, 6 Nov 2001 03:55, Paul Hammant wrote:
> Peter,
>
> Finally! This is what you wanted considered conversation on?
yep ;)
> There are so many ways to answer this. So many choices that mean good
> and bad news for different parties.
>
> 1) WAR should not not able to see or instantiate excalibur (etc) classes
> by default. It's a security issue and I think everyone agrees that.
> Given that Jo! (or Tomcat n years from now) could host Cocoon that
> needs Excalibur (etc) then WAR files as at present must be able to bring
> their own jars that clash with dopplegangers elsewhee in the VM
> (different branch).
yep. Once the deprecated methods are removed from BlockContext this should be
possible.
> 2) What can the IoC pattern do for us here? Could a Phoenix app that
> needs Excalibur classes be given a handle to a suitable classloader by
> asking for it through ComponentManager? This sounds great but I don't
> think it can work at all. All dependancies are resolved at load time
> via a zillion findClass() calls. If one is missing (interface or class)
> it will barf in a very unhelpful way.
I would have any jars that need it declare a dependency on Excalibur jar via
standard 1.3 Extensions mechanism.
> 5) Another IoC solution. Could Phoenix apps be able to see everything
> as at present (in CL terms). Could they also go back to some
> componentManager or BlockContext supplied thing and ask for a naked hook
> to the system class loader (is that not called primordial now?) I.e
> Phoenix design recognises that Phoenix hosted apps may want to host
> multiple sub apps that are Pheonix/Avalon/Excalibur/Logkit unaware.
> Either the block can ask for a single CL that has a parent of the
> primordial, and with that itself makes multiple classloaders for it's
> hosted applications. It is not so hard for an app to do this....
> Jesktop does. Or it can be more of a factory and generate new ones on
> request. I'd really prefer the former or a facility for both.
System classloader can still be grabbed from
ClassLoader.getSystemClassLoader(). However the real issue here is for
something like mailet/servlet APIs.
The blocks have to have the Servlet/Mailet interfaces in their classloader.
However the specs dictate that an actual servlet must not be able to see the
container implementation classes.
Hence the servlet classes have to be in a parent classloader to the one in
which the blocks are loaded from and the contained servlets etc have have
their parent classloader set to that classloader aswell.
> 6) Bridging. We're not addressing that in this thread huh? When I get
> more used to BCEL I think I might be able to make the perfect version
> tolerate proxy style bridge for SAR to SAR connecting.
yep. We may be able to get away with jdk1.3 proxies unless speed becomes an
issue.
> 7) Hierarchcy in server.xml. Relaing to (5) above. I think this should
> not be so statically defined.
Can you say where you would want it to be dynamic. I haven't seen any
applications that would have a dynamic CL.
> If it is anywhere it is in assembly.xml
> and a component that can be delivered through compose(..).
I disagree. Assembly.xml is for configuring peer relationships between
components. Server.xml is for setting up the "environment" in which the
application executes.
> In summary, I think we could have a service called :
>
> NonPhoenixClassLoaderEnvironment {
> ClassLoader getNonPhoenixClassLoader();
> }
>
> Phoenix could provide a default implementation of that but other coders
> could provide alternatives (possibly even chained ones).
Services wont do IMO because the blocks them selves need to be loaded from
these ClassLoaders in very specific hierarchies.
Essentially what I want to be able to do is to create a
servlet/mailet/whateverlet server that abides by all the rules but does not
need to resort to ugly classloader hacks to get working. Not sure - may need
more gestation time ;)
--
Cheers,
Pete
---------------------------------------------------
"Therefore it can be said that victorious warriors
win first, and then go to battle, while defeated
warriors go to battle first, and then seek to win."
- Sun Tzu, the Art Of War
---------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
