Hey, thanks for the feedback.
Of course I could use a hand, but I think it's better to run
a couple of
"proposition/feedback/next proposition" cycles and
keep the
responsibility in one hand until we reach a certain level of
content.
But regarding your questions:
* WebServiceRuntime: Fine with me.
* DeploymentAspectManager: We could keep that internal to
the
WebServiceRuntime, but this would lead to arbitrary
internal
implementations of different runtimes. I'd more likely
enforce
the pattern across all WebServiceRuntimes by making it part
of the SPI.
IMO a runtime used within the ESB should look the same then
one that's
used in embedded mode.
But actually there is a little more to it: That "chain
of
responsibility" pattern the DeploymentAspectManager
represents, models a
clear extension point. People grasp it and it enables
injection of
arbitrary extension points. I do actually consider features
like this
part of an API.
* DeploymentModel: We can have convenience methods above
the
DeploymentModel, i.e. simple usage of Endpoints, but at the
lowest part
of the SPI it should be precise. IMO there is always
Deployment->Service->Endpoints.
/Heiko
On Thu, 2008-04-24 at 16:53 +0200, Richard Opalka wrote:
> Hi Heiko,
>
> I finally found some time to study the SPI 3.0 M1
first cut.
> I identified the following basic building blocks of the
new SPI:
>
> * InvocationHandler
> * RequestHandler
> * EndpointRegistry
> * TransportManager
> * WSFRuntime
> * DeploymentAspect
> * DeploymentModel
>
> Comments:
>
> * I don't like WSFRuntime interface name.
> WebServiceRuntime would be a better term.
> * I don't like there are DeploymentAspects involed.
> I guess your next step is to remove dependency on
them?
> * The DeploymentModel is going to be part of the SPI
3.0
> or it's just part of this first prototype?
>
> Questions:
>
> * What is going to change in SPI 3.0 M2?
> * When do you plan to provide SPI 3.0 M2 for preview?
> * Don't you need help with some parts of SPI 3.0?
>
> Richard
>
> Heiko Braun wrote:
> > Yesterday I commited the first cut of SPI 3
migration to
> >
> > - Container 4.2.2, 4.2.3 and 5.0.1
> > - Native and CXF
> >
> > Tonight Hudson runs seem to be OK, except for some
JAX-RPC regression in
> > Native. I am going to look at it today.
> >
> > One that is done, I am planning to continue with
Metro and then finally
> > take a look at the remaining containers 4.2.1 and
5.0.0.
> >
> > One of the things you already look at is the new
Transport API, which
> > allows us to use JBossWS embedded. Currently this
features resides with
> > native. Samples can be found under
'tests/embedded'.
> >
> > Rock on'
> >
> >
> >
> > _______________________________________________
> > jbossws-dev mailing list
> > jbossws-dev lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/jbossws-dev
> >
>
_______________________________________________
jbossws-dev mailing list
jbossws-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbossws-dev
|
Richard
Heiko Braun wrote:
> Yesterday I commited the first cut of SPI 3 migration
to
>
> - Container 4.2.2, 4.2.3 and 5.0.1
> - Native and CXF
>
> Tonight Hudson runs seem to be OK, except for some
JAX-RPC regression in
> Native. I am going to look at it today.
>
> One that is done, I am planning to continue with Metro
and then finally
> take a look at the remaining containers 4.2.1 and
5.0.0.
>
> One of the things you already look at is the new
Transport API, which
> allows us to use JBossWS embedded. Currently this
features resides with
> native. Samples can be found under 'tests/embedded'.
>
> Rock on'
>
>
>
> _______________________________________________
> jbossws-dev mailing list
> jbossws-dev