Kurt Schrader wrote:

>On Wed, 5 Jun 2002, Nicola Ken Barozzi wrote:
>
>  
>
>>Well, Cocoon is made to run on anything, given that the proper Environment
>>classes are coded.
>>Currently it sits on top of a servlet, but it's more of a hack that comes
>>out of necessity.
>>We use nothing of the servlet stuff, and the classloading tomcat does always
>>gives us headaches.
>>
>>Cocoon should really be a Phoenix server application, on the same level of
>>James, Tomcat, Turbine, etc...
>>
>>Since Avalon framework and Excalibur are basically Avalon-commons, they are
>>used at all levels: in phoenix, in server apps, in block, in classes, etc.
>>
>>This means that Turbine would sit on phoenix (and have a standard way of
>>using services), while keeping the ability of defining it's own components.
>>Phoenix would give Turbine all the services for free, and add admin
>>capability (in the works), that would be consistent across all Phoenix apps.
>>    
>>
>
>While all of this sounds very nice, I know that myself and a number of
>other Turbine developers have a need to continue using Turbine as a
>standard servlet packed inside of a .war that we can drop into a servlet
>container.  As far as I can tell from this discussion so far, using
>Phoenix would no longer allow this to happen, or at least not in an
>elegant manner.  Am I just off base here?  Can Phoenix be bootstrapped
>from a servlet and be run that way?
>

Kurt:

Phoenix (today) cannot be (easily) bootstrapped from within a Servlet.
But that's not really an issue.

Once you have your object as components (i.e. conformant with the Avalon 
framework lifecycle patterns) its really academic how those components 
get deployed.  We (OSM) have lots of components, some of which are 
embedded inside servlets, some embedded in an ORB, some leverage Merlin 
(a component assembler and execution utility), some use Merlin as a 
utility embedded inside a component, some will be deployed as 
applications inside Phoenix, and some of them are even auto-magically 
created in the client environment based on server request.  The bottom 
line is that all of there different paths are violently converging as we 
speak - and the end result is that your component will not not need to 
know what its running in ... could be a servlet, could be Phoenix, could 
be Merlin, could be something custom - its not an issue - because its 
just a component and there lots of ways to play with components - and as 
of a few weeks ago - the constraints on the definition of a component 
have been re-crafted so that its pure lifecycle support ... i.e.

    java.lang.Object == potential component
    java.lang.Object + Avalon lifecycles == tangible component
    java.lang.Object + Avalon lifecycles + meta info == magic!

Cheers, Steve.


>
>-Kurt
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to