You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2006/01/13 14:48:00 UTC
o.a.t.binding.axis.config.AxisWebAppLifecycleListener
There's a TODO in
o.a.t.binding.axis.config.AxisWebAppLifecycleListenerabout being a
Tomcat LifecycleListener or web app listener:
http://svn.apache.org/repos/asf/incubator/tuscany/contrib/java/trunk/runtime/binding.axis/src/main/java/org/apache/tuscany/binding/axis/config/AxisWebAppLifecycleListener.java
Is anyone looking at this right now?
I ask mainly as I'd like to be able to use Axis's Simple HTTP server to test
entryPoints with WS bindings, but that doesn't work right now with
AxisWebAppLifecycleListener being a Tomcat LifecycleListener. I know you can
do Tomcat debugging within eclipse but its hard to go back once you're used
to the sub-second startup time of the simple axis server.
...ant
Re: o.a.t.binding.axis.config.AxisWebAppLifecycleListener
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Ant,
I just removed AxisWebAppLifecycleListener. We were using it at some
point but I think it's not needed anymore. The configuration of Axis is
now triggered from o.a.t.binding.axis.handler.WebServiceEntryPointServlet.
What are your requirements for running inside the Axis simple HTTP
server? Will the current WebServiceEntryPointServlet work for you?
--
Jean-Sebastien
Jim Marino wrote:
> You may want take a look at some of the refactoring around
> o.a.t.core.context and in particular the Context hierarchy
> (AggregateContext, EntryPoint Context, etc.). The unit tests may be
> helpful in seeing how components and entry points can be registered
> with the system from a unit test.
>
> Part of this work is a start to how I'd like to refactor entry points
> and external services to be contexts that can be integrated with Axis
> handlers. For instance, it should be possible to have a request
> processed by Axis first and then have the last handler send a message
> through an entry point (which may have a series of additional
> handlers), or have a very lightweight listener on a transport (e.g.
> Servlet) which passes a request to the entry point as a message, that
> in turn has a series of handlers which invoke the Axis pipeline.
>
> This will allow a more centralized management of entry points (e.g.
> they are just contexts), compact wiring code (I've already done this
> with the system binding), as well as the ability to mix-and-match
> handlers from different libraries using flexible ordering. Also, in
> terms of the use case you mentioned, I don't think you would need to
> even have to deal with an HTTP sever at all.
>
> Jim
>
>
>
> On Jan 13, 2006, at 5:48 AM, ant elder wrote:
>
>> There's a TODO in
>> o.a.t.binding.axis.config.AxisWebAppLifecycleListenerabout being a
>> Tomcat LifecycleListener or web app listener:
>> http://svn.apache.org/repos/asf/incubator/tuscany/contrib/java/trunk/runtime/binding.axis/src/main/java/org/apache/tuscany/binding/axis/config/AxisWebAppLifecycleListener.java
>>
>>
>> Is anyone looking at this right now?
>>
>> I ask mainly as I'd like to be able to use Axis's Simple HTTP server
>> to test
>> entryPoints with WS bindings, but that doesn't work right now with
>> AxisWebAppLifecycleListener being a Tomcat LifecycleListener. I know
>> you can
>> do Tomcat debugging within eclipse but its hard to go back once
>> you're used
>> to the sub-second startup time of the simple axis server.
>>
>> ...ant
>>
>
>
Re: o.a.t.binding.axis.config.AxisWebAppLifecycleListener
Posted by Jim Marino <jm...@myroma.net>.
You may want take a look at some of the refactoring around
o.a.t.core.context and in particular the Context hierarchy
(AggregateContext, EntryPoint Context, etc.). The unit tests may be
helpful in seeing how components and entry points can be registered
with the system from a unit test.
Part of this work is a start to how I'd like to refactor entry points
and external services to be contexts that can be integrated with Axis
handlers. For instance, it should be possible to have a request
processed by Axis first and then have the last handler send a message
through an entry point (which may have a series of additional
handlers), or have a very lightweight listener on a transport (e.g.
Servlet) which passes a request to the entry point as a message, that
in turn has a series of handlers which invoke the Axis pipeline.
This will allow a more centralized management of entry points (e.g.
they are just contexts), compact wiring code (I've already done this
with the system binding), as well as the ability to mix-and-match
handlers from different libraries using flexible ordering. Also, in
terms of the use case you mentioned, I don't think you would need to
even have to deal with an HTTP sever at all.
Jim
On Jan 13, 2006, at 5:48 AM, ant elder wrote:
> There's a TODO in
> o.a.t.binding.axis.config.AxisWebAppLifecycleListenerabout being a
> Tomcat LifecycleListener or web app listener:
> http://svn.apache.org/repos/asf/incubator/tuscany/contrib/java/
> trunk/runtime/binding.axis/src/main/java/org/apache/tuscany/binding/
> axis/config/AxisWebAppLifecycleListener.java
>
> Is anyone looking at this right now?
>
> I ask mainly as I'd like to be able to use Axis's Simple HTTP
> server to test
> entryPoints with WS bindings, but that doesn't work right now with
> AxisWebAppLifecycleListener being a Tomcat LifecycleListener. I
> know you can
> do Tomcat debugging within eclipse but its hard to go back once
> you're used
> to the sub-second startup time of the simple axis server.
>
> ...ant
>