Peter, >> How >> does Phoenix's ClassLoader complicate modifying ClassLoader >> hierarchies...what problems should I watch out for?
>Essentially the problem occurs when you try to have a Phoenix Block implement >part of Catalinas container. So for example if you wanted to use Cornerstones >SocketManager and expose it in Catalina. The Catalina class would have to >have both the cornerstone/phoenix classes and the catalina classes. > >As standard hierarchies only allow one parent this is not possible unless you >expose Cornerstone/Phoenix to all of Catalina (including the webapps). >However the servlet spec requires that webapps should not be able to see the >containers classloader. So, a Web app should not have the Phoenix classloader in its heirarchy? > >Anyways thats why I am working on loader stuff to incorporate into Phoenix. I looked at you loader stuff...very cool! I think we need a better specification for Sevak. What is its purpose? How should it interoperate with other apps. Is it simply about embedding an existing Servlet Container within Phoenix or is it about creating an abstract container that can utilize implementations of existing containers? I think in the long run, we need to define a complete set of services that establish Sevak as a working interface specification and begin to adapt existing containers to this specification. Thoughts? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
