Jetty server is always created

[Simon Nash <na...@hursley.ibm.com>]

When bringing up the Tuscany core runtime with no usage of any
extensions, a Jetty server is always created.  AIUI, this should
only happen when creating a service that has a Web services binding.

The code that creates the Jetty server is in the start method of
org.apache.tuscany.http.jetty.module.JettyRuntimeModuleActivator.
This appears to be another symptom of the lifecycle-related
problems that were introduced when the fine-grained lifecycle support
based on AbstractLifecycle and AbstractSCAObject was changed to use
the ModuleActivator approach.

   Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Jetty server is always created

[Simon Nash <na...@hursley.ibm.com>]

Thanks for this very helpful explanation of the mechanisms involved.
I checked the code again and I was wrong to say that the Jetty server
is being created in step 2.  The object that is being created here is
org.apache.tuscany.http.jetty.JettyServer, not org.mortbay.jetty.Server.
My apologies for the name confusion.  As you say, the Jetty server
is being created in step 4, by JettyServer.addServletMapping().
I also looked at the code from the integration branch, and it appeared
that the Jetty server was created in step 4 there as well, by
JettyServiceImpl.registerMapping().

I was using the tuscany-all.jar, and I saw the other thread of
discussion about why this causes the more aggressive loading to
happen.  We can continue the discussion about options to solve
this problem on that other thread.

 From your description of the new lifecycle handling points, it sounds
like these will do everything we need.  When Raymond has finished
implementing these, I'll update my fix to TUSCANY-1218 to use the
new new lifecycle mechanisms.

   Simon

Jean-Sebastien Delfino wrote:

> Comments inline.
> 
> Simon Nash wrote:
> 
>> When bringing up the Tuscany core runtime with no usage of any
>> extensions, a Jetty server is always created.  AIUI, this should
>> only happen when creating a service that has a Web services binding.
>>
> 
> The creation of an instance of our JettyServer class should only happen 
> if you've decided to include that module in your environment. Most of 
> our samples do not have it on their classpath, and they shouldn't if 
> they're not running at all as a server.
> 
> How are you running your application? I am running the calculator sample 
> an I don't see a JettyServer created.
> 
> Or are you using the tuscany-all JAR? I just checked it and I think that 
> the distribution build script puts too much in it... as it contains both 
> the http-jetty and http-tomcat modules, two web servers are probably too 
> much :), and we should actually probably keep these out of this JAR anyway.
> 
>> The code that creates the Jetty server is in the start method of
>> org.apache.tuscany.http.jetty.module.JettyRuntimeModuleActivator.
>> This appears to be another symptom of the lifecycle-related
>> problems that were introduced when the fine-grained lifecycle support
>> based on AbstractLifecycle and AbstractSCAObject was changed to use
>> the ModuleActivator approach.
> 
> 
> There may be a little bit of confusion here. We have not really replaced 
> AbstractLifecycle by ModuleActivator.
> 
> Here are the various lifecycle handling points:
> 1. ModuleActivator.getExtensionPoints() - invoked first when the runtime 
> starts and finds the available modules, gives an opportunity to a module 
> to contribute extension points
> 2. ModuleActivator.start()/stop() - invoked when the runtime starts and 
> gives an opportunity to modules to register extensions
> 3. 
> Implementation/ReferenceBinding/ServiceBindingActivator.start()/stop() - 
> invoked when a component gets started/stopped to give component 
> implementations, reference and service bindings an opportunity to 
> start/stop.
> 4. ImplementationProvider.createInstance() and the interaction with the 
> scope container is the last level of lifecycle management.
> 
> It looks like Raymond is in the middle of porting some of the core 
> runtime to the newer interfaces so some code may still reference 
> AbstractLifecycle, newer code may already reference the new interfaces.
> 
> Going back to the JettyServer case, here's how I think it works:
> 1. SCARuntime starts.
> 2. All modules configured in your environment are started with 
> ModuleActivator.getExtensionPoints() and then start(). JettyServer gets 
> registered as a ServletHost extension, but a Jetty Server instance is 
> not created and not started at this point.
> 3. Composites are loaded, a WS binding is found, Axis2ServiceBinding 
> instances get created and register their servlets with a URI into 
> ServletHost.
> 4. ServletHost delegates to JettyServer to register each servlet, the 
> Jetty Server actually starts at this point Ant, Ignacio and myself had 
> discussions on this list to see how to handle multiple HTTP ports / 
> connectors and I think that Ant has started to look into that.
> 5. Axis2ServiceBinding.start() should be called next on each 
> service/reference with a WS binding - this is probably not happening yet 
> as I believe that the Axis2ServiceBinding has not been ported to the 
> latest interfaces yet.
> 
> When everything is ported over to the new interfaces the registration of 
> the servlet (and the start of the Jetty instance) will happen in step 5 
> instead of 4, which actually won't really change much in terms of timing...
> 
> Comparing this with what we had in the past:
> - in the environment we had in the integration branch, a Jetty server 
> was started - as a system composite scoped component instead of a module 
> - in step 2 if I remember correctly
> - before that, we were running on top of Tomcat, and Tomcat was always 
> started as well, first even before SCA, in step 0 :)
> 
> Hope this helps.
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Jetty server is always created

[Jean-Sebastien Delfino <js...@apache.org>]

Comments inline.

Simon Nash wrote:
> When bringing up the Tuscany core runtime with no usage of any
> extensions, a Jetty server is always created.  AIUI, this should
> only happen when creating a service that has a Web services binding.
>

The creation of an instance of our JettyServer class should only happen 
if you've decided to include that module in your environment. Most of 
our samples do not have it on their classpath, and they shouldn't if 
they're not running at all as a server.

How are you running your application? I am running the calculator sample 
an I don't see a JettyServer created.

Or are you using the tuscany-all JAR? I just checked it and I think that 
the distribution build script puts too much in it... as it contains both 
the http-jetty and http-tomcat modules, two web servers are probably too 
much :), and we should actually probably keep these out of this JAR anyway.

> The code that creates the Jetty server is in the start method of
> org.apache.tuscany.http.jetty.module.JettyRuntimeModuleActivator.
> This appears to be another symptom of the lifecycle-related
> problems that were introduced when the fine-grained lifecycle support
> based on AbstractLifecycle and AbstractSCAObject was changed to use
> the ModuleActivator approach.

There may be a little bit of confusion here. We have not really replaced 
AbstractLifecycle by ModuleActivator.

Here are the various lifecycle handling points:
1. ModuleActivator.getExtensionPoints() - invoked first when the runtime 
starts and finds the available modules, gives an opportunity to a module 
to contribute extension points
2. ModuleActivator.start()/stop() - invoked when the runtime starts and 
gives an opportunity to modules to register extensions
3. 
Implementation/ReferenceBinding/ServiceBindingActivator.start()/stop() - 
invoked when a component gets started/stopped to give component 
implementations, reference and service bindings an opportunity to 
start/stop.
4. ImplementationProvider.createInstance() and the interaction with the 
scope container is the last level of lifecycle management.

It looks like Raymond is in the middle of porting some of the core 
runtime to the newer interfaces so some code may still reference 
AbstractLifecycle, newer code may already reference the new interfaces.

Going back to the JettyServer case, here's how I think it works:
1. SCARuntime starts.
2. All modules configured in your environment are started with 
ModuleActivator.getExtensionPoints() and then start(). JettyServer gets 
registered as a ServletHost extension, but a Jetty Server instance is 
not created and not started at this point.
3. Composites are loaded, a WS binding is found, Axis2ServiceBinding 
instances get created and register their servlets with a URI into 
ServletHost.
4. ServletHost delegates to JettyServer to register each servlet, the 
Jetty Server actually starts at this point Ant, Ignacio and myself had 
discussions on this list to see how to handle multiple HTTP ports / 
connectors and I think that Ant has started to look into that.
5. Axis2ServiceBinding.start() should be called next on each 
service/reference with a WS binding - this is probably not happening yet 
as I believe that the Axis2ServiceBinding has not been ported to the 
latest interfaces yet.

When everything is ported over to the new interfaces the registration of 
the servlet (and the start of the Jetty instance) will happen in step 5 
instead of 4, which actually won't really change much in terms of timing...

Comparing this with what we had in the past:
- in the environment we had in the integration branch, a Jetty server 
was started - as a system composite scoped component instead of a module 
- in step 2 if I remember correctly
- before that, we were running on top of Tomcat, and Tomcat was always 
started as well, first even before SCA, in step 0 :)

Hope this helps.

>
>   Simon
>
-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org