You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Yang ZHONG <le...@gmail.com> on 2006/08/30 12:20:32 UTC
Re: Delivery Status Notification (Failure)
Neither tuscany-dev nor infra takes my email with attachment, so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677
Sorry for the inconvenience and thanks for any comment.
On 8/30/06, Mail Delivery Subsystem <ma...@googlemail.com> wrote:
>
> This is an automatically generated Delivery Status Notification
>
> Delivery to the following recipient failed permanently:
>
> infra@ws.apache.org
>
> Technical details of permanent failure:
> PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it is spam
> (body)
>
> ----- Original message -----
>
> Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
> Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
> Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41 -0700 (PDT)
> Message-ID: <ea...@mail.gmail.com>
> Date: Wed, 30 Aug 2006 03:06:41 -0700
> From: "Yang ZHONG" <le...@gmail.com>
> To: tuscany-dev@ws.apache.org
> Subject: Re: Auto discovering WSDL
> Cc: infra@ws.apache.org
> In-Reply-To: <ea...@mail.gmail.com>
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
> boundary="----=_Part_28704_31437365.1156932401933"
> References: <
> 244F5835C09CB641AE1D928BB2B0B9D8021CCD17@amereast-ems2.IONAGLOBAL.COM>
> <ea...@mail.gmail.com>
> <ea...@mail.gmail.com>
> <71...@mail.gmail.com>
> <ea...@mail.gmail.com>
>
> ------=_Part_28704_31437365.1156932401933
> Content-Type: multipart/alternative;
> boundary="----=_Part_28705_19724073.1156932401933"
>
> ------=_Part_28705_19724073.1156932401933
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> Could you please review the registry API and SPI?
>
> ----- Message truncated -----
>
>
--
Yang ZHONG
Meaningful subjects, was: Delivery Status Notification (Failure)
Posted by Jeremy Boynes <jb...@apache.org>.
Can people please make sure that messages have subjects that have
some relationship to their content.
--
Jeremy
On Aug 30, 2006, at 3:20 AM, Yang ZHONG wrote:
> Neither tuscany-dev nor infra takes my email with attachment, so I've
> attached file for review into
> http://issues.apache.org/jira/browse/TUSCANY-677
>
> Sorry for the inconvenience and thanks for any comment.
>
> On 8/30/06, Mail Delivery Subsystem <ma...@googlemail.com>
> wrote:
>>
>> This is an automatically generated Delivery Status Notification
>>
>> Delivery to the following recipient failed permanently:
>>
>> infra@ws.apache.org
>>
>> Technical details of permanent failure:
>> PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it is
>> spam
>> (body)
>>
>> ----- Original message -----
>>
>> Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
>> Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
>> Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
>> -0700 (PDT)
>> Message-ID:
>> <ea...@mail.gmail.com>
>> Date: Wed, 30 Aug 2006 03:06:41 -0700
>> From: "Yang ZHONG" <le...@gmail.com>
>> To: tuscany-dev@ws.apache.org
>> Subject: Re: Auto discovering WSDL
>> Cc: infra@ws.apache.org
>> In-Reply-To:
>> <ea...@mail.gmail.com>
>> MIME-Version: 1.0
>> Content-Type: multipart/mixed;
>> boundary="----=_Part_28704_31437365.1156932401933"
>> References: <
>> 244F5835C09CB641AE1D928BB2B0B9D8021CCD17@amereast-
>> ems2.IONAGLOBAL.COM>
>> <ea...@mail.gmail.com>
>> <ea...@mail.gmail.com>
>> <71...@mail.gmail.com>
>> <ea...@mail.gmail.com>
>>
>> ------=_Part_28704_31437365.1156932401933
>> Content-Type: multipart/alternative;
>> boundary="----=_Part_28705_19724073.1156932401933"
>>
>> ------=_Part_28705_19724073.1156932401933
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> Content-Transfer-Encoding: 7bit
>> Content-Disposition: inline
>>
>> Could you please review the registry API and SPI?
>>
>> ----- Message truncated -----
>>
>>
>
>
> --
>
> Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Jim, I don't think it should be checked into SDO for the same reasons you
mentioned below. SDO needs a Type and (global) Property registry. It would
be nice if we could have a simple generic design that could be used for
that and also for SCA/WSDL, but maybe that's not possible.
Frank.
Jim Marino <jm...@myromatours.com> wrote on 09/20/2006 01:08:56 PM:
> Comments inline. Frank, in case you miss it below, could you comment
> on if perhaps Yang's generic registry is something that is more
> appropriate for checking into SDO?
>
> Jim
>
> On Sep 20, 2006, at 2:30 AM, Yang ZHONG wrote:
>
> >>
> >> Looking at the implementation, I think there may be a rather large
> >> disconnect in our views of what needs to be accomplished. So, I will
> >> start by describing what I thought we are and are not trying to do...
> >>
> >> I thought we were trying to provide a registry which would resolve
> >> *WSDL* artifacts to be used by binding (or other) extensions during
> >> the build phase as an assembly is processed. These artifacts would be
> >> used by the extensions to create appropriate runtime artifacts. The
> >> goals of this WSDL registry would be primarily to provide a mechanism
> >> where WSDL artifacts could be resolved and processed using a variety
> >> of extensible strategies and, secondarily, as a way to cache them
> >> (although whether caching produces significant performance gains
> >> given typical runtime uses cases is debatable). From an
> >> implementation perspective, the registry would rely on the runtime to
> >> provide the proper visibility constraints which would alleviate the
> >> former from having to provide scoping behavior such as keying on
> >> classloader. Tuscany has a DeploymentContext that could be used to
> >> hold the registry and maintain proper isolation between composites.
> >
> >
> > Thanks a lot for so concrete requirement.
> >
> > What I thought we were *not* trying to accomplish is to provide a
> >> "generic" registry that caches a variety of artifacts and provides
> >> built-in scoping for a number of host environments (e.g. Tuscany,
> >
> >
> > Scoping are not really built-in;
> > a SPI (org.apache.tuscany.registry.spi.Scoping) is required
> > implemented.
> > The Reference Implementation provides the ClassLoader one *just*
> > for Java
> > users' convenience.
> >
> > some tool, etc.). Based on the implementation and things like the
> >> package structure (e.g. org.apache.tuscany.registry), I suspect you
> >> may disagree with this. From a project perspective, one of my
> >> concerns here is that we should not be expanding the charter of
> >> Tuscany to include an additional technology category at this point (a
> >> generic registry). From a technology perspective, I have the
> >> following concerns:
> >>
> >> - The majority of the implementation appears to offer features not
> >> required by the runtime (e.g util, scoping, all of the stuff related
> >> to multiple keys in SPI and API)
> >
> >
> > Yes, the Reference Implementation (RI) does provide much more
> > functions than
> > you expected.
> >
> > However, it's better than nothing. At least folks can start to use
> > WSDL
> > Registry
> > whose API is *not* bound to the RI at all.
> > The RI does *not* prevent us from implementing the WSDL Registry
> > API from
> > scratch as you suggested.
> > While folks are able to use the WSDL Registry, we can go for other
> > implementation(s) in parallel.
> >
> I don't believe we should check this code in for the reasons I
> previously mentioned. IMO we should work on an implementation that
> fulfills the requirements that I mentioned above, namely something
> that resolves WSDL artifacts.
> > On the other hand, Frank and I talked about the registry the other day
> > and we both think it might be something useful for SDO Type
> > registry (and
> > Global Property registry).
> > And Fuhwei's team needs a registry too.
> > SCA and SDO as one Tuscany team don't have to duplicate similar
> > effort.
> >
> If SDO requires a generic registry, perhaps it is best that Frank,
> Kelvin or one of the other committers working in that area review
> your patch and decide if it fits their requirements and check it into
> the SDO subproject? I don't think this should be checked in as a
> sibling project to SDO, DAS, or SCA as that expands the Tuscany
> charter. I am also not comfortable with the Java SCA runtime sharing
> source code between subprojects as we (I should say Jeremy) just
> spent a lot of time decoupling them.
>
> Frank, do you feel this is something that could be checked into SDO?
>
> > If it ends up used by no one, and we have a new implementation for
> > the WSDL
> > Registry API already,
> > we can easily throw the RI away and I don't see it hurt anything
> > (it will *not* hurt my feeling since I volunteered and it's my
> > interest to
> > help with my experience anyway)
> >
> I'd prefer we work on a solution that addresses the specific runtime
> requirements we have without introducing unneeded complexity, keeping
> in mind YAGNI.
> > - It is difficult to follow and does not appear to be similar to how
> >> other extensions are architected (e.g. loaders, builders,
> >> databinding). I still don't understand what the extension points are
> >> or how I would use the SPI.
> >
> >
> > Builders and DataBinding are SCA architects which I'm not confident
> > enough
> > to discuss about.
> > I'd like to learn even if I don't see them related to the registry
> > so far,
> > maybe the education can teach me more requirements of a registry.
> >
> Registry may be a misnomer: maybe resolver is a better term?
> >
>
> > You had pointed me to Celtix's WSDLManager
> > and I changed the WSDL Registry API proposal.
> > No comment since then and I thought you were fine with the new
> > proposal.
> > Sorry if I misunderstood, what's your new suggestions please?
> >
> Sorry I was out due to personal reasons. I think I kind of laid out
> how I would approach this in prior emails:
>
> - Define an API similar to what Celtix has. We've partially done this.
> - Implement the WSDL registry similar to how builders and loaders are
> done. These use simple collections to cache configuration artifacts
> that are disposed of after the build process. The registries don't
> need to handle visibility constraints themselves, instead relying on
> the runtime to do that. This would mean we don't need any of the
> pluggable scoping, etc.
> - Have pluggable resolvers as mentioned by Jervis. We may/will have
> some work to do in the runtime to get it to support this but can
> address that once we have a basic implementation.
>
> Jim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Jim Marino <jm...@myromatours.com>.
Comments inline. Frank, in case you miss it below, could you comment
on if perhaps Yang's generic registry is something that is more
appropriate for checking into SDO?
Jim
On Sep 20, 2006, at 2:30 AM, Yang ZHONG wrote:
>>
>> Looking at the implementation, I think there may be a rather large
>> disconnect in our views of what needs to be accomplished. So, I will
>> start by describing what I thought we are and are not trying to do...
>>
>> I thought we were trying to provide a registry which would resolve
>> *WSDL* artifacts to be used by binding (or other) extensions during
>> the build phase as an assembly is processed. These artifacts would be
>> used by the extensions to create appropriate runtime artifacts. The
>> goals of this WSDL registry would be primarily to provide a mechanism
>> where WSDL artifacts could be resolved and processed using a variety
>> of extensible strategies and, secondarily, as a way to cache them
>> (although whether caching produces significant performance gains
>> given typical runtime uses cases is debatable). From an
>> implementation perspective, the registry would rely on the runtime to
>> provide the proper visibility constraints which would alleviate the
>> former from having to provide scoping behavior such as keying on
>> classloader. Tuscany has a DeploymentContext that could be used to
>> hold the registry and maintain proper isolation between composites.
>
>
> Thanks a lot for so concrete requirement.
>
> What I thought we were *not* trying to accomplish is to provide a
>> "generic" registry that caches a variety of artifacts and provides
>> built-in scoping for a number of host environments (e.g. Tuscany,
>
>
> Scoping are not really built-in;
> a SPI (org.apache.tuscany.registry.spi.Scoping) is required
> implemented.
> The Reference Implementation provides the ClassLoader one *just*
> for Java
> users' convenience.
>
> some tool, etc.). Based on the implementation and things like the
>> package structure (e.g. org.apache.tuscany.registry), I suspect you
>> may disagree with this. From a project perspective, one of my
>> concerns here is that we should not be expanding the charter of
>> Tuscany to include an additional technology category at this point (a
>> generic registry). From a technology perspective, I have the
>> following concerns:
>>
>> - The majority of the implementation appears to offer features not
>> required by the runtime (e.g util, scoping, all of the stuff related
>> to multiple keys in SPI and API)
>
>
> Yes, the Reference Implementation (RI) does provide much more
> functions than
> you expected.
>
> However, it's better than nothing. At least folks can start to use
> WSDL
> Registry
> whose API is *not* bound to the RI at all.
> The RI does *not* prevent us from implementing the WSDL Registry
> API from
> scratch as you suggested.
> While folks are able to use the WSDL Registry, we can go for other
> implementation(s) in parallel.
>
I don't believe we should check this code in for the reasons I
previously mentioned. IMO we should work on an implementation that
fulfills the requirements that I mentioned above, namely something
that resolves WSDL artifacts.
> On the other hand, Frank and I talked about the registry the other day
> and we both think it might be something useful for SDO Type
> registry (and
> Global Property registry).
> And Fuhwei's team needs a registry too.
> SCA and SDO as one Tuscany team don't have to duplicate similar
> effort.
>
If SDO requires a generic registry, perhaps it is best that Frank,
Kelvin or one of the other committers working in that area review
your patch and decide if it fits their requirements and check it into
the SDO subproject? I don't think this should be checked in as a
sibling project to SDO, DAS, or SCA as that expands the Tuscany
charter. I am also not comfortable with the Java SCA runtime sharing
source code between subprojects as we (I should say Jeremy) just
spent a lot of time decoupling them.
Frank, do you feel this is something that could be checked into SDO?
> If it ends up used by no one, and we have a new implementation for
> the WSDL
> Registry API already,
> we can easily throw the RI away and I don't see it hurt anything
> (it will *not* hurt my feeling since I volunteered and it's my
> interest to
> help with my experience anyway)
>
I'd prefer we work on a solution that addresses the specific runtime
requirements we have without introducing unneeded complexity, keeping
in mind YAGNI.
> - It is difficult to follow and does not appear to be similar to how
>> other extensions are architected (e.g. loaders, builders,
>> databinding). I still don't understand what the extension points are
>> or how I would use the SPI.
>
>
> Builders and DataBinding are SCA architects which I'm not confident
> enough
> to discuss about.
> I'd like to learn even if I don't see them related to the registry
> so far,
> maybe the education can teach me more requirements of a registry.
>
Registry may be a misnomer: maybe resolver is a better term?
>
> You had pointed me to Celtix's WSDLManager
> and I changed the WSDL Registry API proposal.
> No comment since then and I thought you were fine with the new
> proposal.
> Sorry if I misunderstood, what's your new suggestions please?
>
Sorry I was out due to personal reasons. I think I kind of laid out
how I would approach this in prior emails:
- Define an API similar to what Celtix has. We've partially done this.
- Implement the WSDL registry similar to how builders and loaders are
done. These use simple collections to cache configuration artifacts
that are disposed of after the build process. The registries don't
need to handle visibility constraints themselves, instead relying on
the runtime to do that. This would mean we don't need any of the
pluggable scoping, etc.
- Have pluggable resolvers as mentioned by Jervis. We may/will have
some work to do in the runtime to get it to support this but can
address that once we have a basic implementation.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Yang ZHONG <le...@gmail.com>.
Thank Jim for such a detailed response.
I'll brief update first, then address Jim's concerns inline.
A Reference Implementation of WSDL is now available at
http://issues.apache.org/jira/secure/attachment/12341187/registry5.zip
for JIRA
http://issues.apache.org/jira/browse/TUSCANY-677
Please try the live demo at
impl/SCA/WSDL/src/test/java/org/apache/tuscany/registry/sca/wsdl/test
For your convenience, here's the live demo (helloworld.wsdl):
WSDLManager MANAGER = ... (SCA Programming Model)
WSDLRegistries WSDL = MANAGER.getWSDLRegistries(null);
Definition myDefinition = WSDL.getDefinition(myNameSpace);
Registry<Message> messages = WSDL.getMessageRegistry();
Message myMessage = messages.get(myNameSpace, "getGreetingsRequest");
Registry<PortType> interfaces = WSDL.getInterfaceRegistry();
PortType myInterface = interfaces.get(myNameSpace,
"HelloWorldServiceImpl");
Registry<Binding> bindings = WSDL.getBindingRegistry();
Binding myBinding = bindings.get(myNameSpace, "helloworldSoapBinding");
Registry<Service> services = WSDL.getServiceRegistry();
Service myService = services.get(myNameSpace,
"HelloWorldServiceImplService");
TODOs (impl/SCA/WSDL/src/main/java/org/apache/tuscany/registry/sca/wsdl):
CompositeScoping.java, any volunteer to complete the skeleton please?
NameSpaceLocator.java, any volunteer to complete the skeleton to locate
file from CompositeComponent please?
RegistryLoader.java, any volunteer to change to the WSDLReader being
used by SCA please?
WSDLRegistries.java, any volunteer to compute the context
CompositeComponent please?
Jim proposed direct providing
Registry<Message||PortType||Binding||Service> so that users don't have to
WSDL.getXxxRegistry();
any volunteer to support that from SCA please?
And any volunteer to make component files for impl/API and impl/SCA/WSDL
please?
I'm addressing Jim's concerns inline:
On 9/19/06, Jim Marino <jm...@myromatours.com> wrote:
>
> Hi Yang,
>
> Looking at the implementation, I think there may be a rather large
> disconnect in our views of what needs to be accomplished. So, I will
> start by describing what I thought we are and are not trying to do...
>
> I thought we were trying to provide a registry which would resolve
> *WSDL* artifacts to be used by binding (or other) extensions during
> the build phase as an assembly is processed. These artifacts would be
> used by the extensions to create appropriate runtime artifacts. The
> goals of this WSDL registry would be primarily to provide a mechanism
> where WSDL artifacts could be resolved and processed using a variety
> of extensible strategies and, secondarily, as a way to cache them
> (although whether caching produces significant performance gains
> given typical runtime uses cases is debatable). From an
> implementation perspective, the registry would rely on the runtime to
> provide the proper visibility constraints which would alleviate the
> former from having to provide scoping behavior such as keying on
> classloader. Tuscany has a DeploymentContext that could be used to
> hold the registry and maintain proper isolation between composites.
Thanks a lot for so concrete requirement.
What I thought we were *not* trying to accomplish is to provide a
> "generic" registry that caches a variety of artifacts and provides
> built-in scoping for a number of host environments (e.g. Tuscany,
Scoping are not really built-in;
a SPI (org.apache.tuscany.registry.spi.Scoping) is required implemented.
The Reference Implementation provides the ClassLoader one *just* for Java
users' convenience.
some tool, etc.). Based on the implementation and things like the
> package structure (e.g. org.apache.tuscany.registry), I suspect you
> may disagree with this. From a project perspective, one of my
> concerns here is that we should not be expanding the charter of
> Tuscany to include an additional technology category at this point (a
> generic registry). From a technology perspective, I have the
> following concerns:
>
> - The majority of the implementation appears to offer features not
> required by the runtime (e.g util, scoping, all of the stuff related
> to multiple keys in SPI and API)
Yes, the Reference Implementation (RI) does provide much more functions than
you expected.
However, it's better than nothing. At least folks can start to use WSDL
Registry
whose API is *not* bound to the RI at all.
The RI does *not* prevent us from implementing the WSDL Registry API from
scratch as you suggested.
While folks are able to use the WSDL Registry, we can go for other
implementation(s) in parallel.
On the other hand, Frank and I talked about the registry the other day
and we both think it might be something useful for SDO Type registry (and
Global Property registry).
And Fuhwei's team needs a registry too.
SCA and SDO as one Tuscany team don't have to duplicate similar effort.
If it ends up used by no one, and we have a new implementation for the WSDL
Registry API already,
we can easily throw the RI away and I don't see it hurt anything
(it will *not* hurt my feeling since I volunteered and it's my interest to
help with my experience anyway)
- It is difficult to follow and does not appear to be similar to how
> other extensions are architected (e.g. loaders, builders,
> databinding). I still don't understand what the extension points are
> or how I would use the SPI.
Builders and DataBinding are SCA architects which I'm not confident enough
to discuss about.
I'd like to learn even if I don't see them related to the registry so far,
maybe the education can teach me more requirements of a registry.
All
SPI JavaDoc(package.HTML),
impl/API/src/test/java/org/apache/tuscany/registry/test
and the new
impl/SCA/WSDL/src/test/java/org/apache/tuscany/registry/sca/wsdl/test
have sample/examples to use the SPI(Locator and RegistryLoader).
Hope they help and I do see the documentation is far from complete.
I'll try to find time to document more. Also any volunteer (I really don't
want to be a bottleneck)?
- It contains large amounts of untested and undocumented code. I
> would prefer smaller, iterative patches that contain testcases to
> verify functionality.
Yes, tests are even much more worse than documentation.
This's the area volunteers really really really help.
- It still uses static singletons which are anathema to SCA (and
> Tuscany) being based on IoC.
I had removed the API singleton upon your request.
If you meant the SPI one, I've also removed it in the latest update upon
your comment.
Given the vast amount of work ahead of us, could we start with
> defining our objectives for WSDL loading and then define an interface
> for retrieving WSDL artifacts, potentially using Celtix's WSDLManager
> for ideas. From there, we can figure out how to best implement it?
You had pointed me to Celtix's WSDLManager
and I changed the WSDL Registry API proposal.
No comment since then and I thought you were fine with the new proposal.
Sorry if I misunderstood, what's your new suggestions please?
Once we lock down the WSDL Registry API,
we sure can figure out how to best implement it.
(I hope you don't mind a may-be-silly RI for people to start)
Jim
>
>
>
>
>
> As an implementation strategy
Once again, thank Jim very much.
On Sep 18, 2006, at 11:26 AM, Yang ZHONG wrote:
>
> > Thank you all for the patience.
> > (I also used the waiting time to assure no huge change to the API
> > and SPI)
> >
> > A Reference Implementation is now available at
> > http://issues.apache.org/jira/secure/attachment/12341070/
> > registry4.zip
> > for JIRA
> > http://issues.apache.org/jira/browse/TUSCANY-677
> >
> > The implementation has a JavaDoc at
> > impl/SPI/doc
> > and please try the live demo at
> > impl/API/src/test/java/org/apache/tuscany/registry/test
> > demonstrating using SPI to register Locator and loader and using
> > API to get
> > symbol on demand.
> >
> > A WSDL Reference Implementation will be provided next time.
> >
> > --
> >
> > Yang ZHONG
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Jim Marino <jm...@myromatours.com>.
Hi Yang,
Looking at the implementation, I think there may be a rather large
disconnect in our views of what needs to be accomplished. So, I will
start by describing what I thought we are and are not trying to do...
I thought we were trying to provide a registry which would resolve
*WSDL* artifacts to be used by binding (or other) extensions during
the build phase as an assembly is processed. These artifacts would be
used by the extensions to create appropriate runtime artifacts. The
goals of this WSDL registry would be primarily to provide a mechanism
where WSDL artifacts could be resolved and processed using a variety
of extensible strategies and, secondarily, as a way to cache them
(although whether caching produces significant performance gains
given typical runtime uses cases is debatable). From an
implementation perspective, the registry would rely on the runtime to
provide the proper visibility constraints which would alleviate the
former from having to provide scoping behavior such as keying on
classloader. Tuscany has a DeploymentContext that could be used to
hold the registry and maintain proper isolation between composites.
What I thought we were *not* trying to accomplish is to provide a
"generic" registry that caches a variety of artifacts and provides
built-in scoping for a number of host environments (e.g. Tuscany,
some tool, etc.). Based on the implementation and things like the
package structure (e.g. org.apache.tuscany.registry), I suspect you
may disagree with this. From a project perspective, one of my
concerns here is that we should not be expanding the charter of
Tuscany to include an additional technology category at this point (a
generic registry). From a technology perspective, I have the
following concerns:
- The majority of the implementation appears to offer features not
required by the runtime (e.g util, scoping, all of the stuff related
to multiple keys in SPI and API)
- It is difficult to follow and does not appear to be similar to how
other extensions are architected (e.g. loaders, builders,
databinding). I still don't understand what the extension points are
or how I would use the SPI.
- It contains large amounts of untested and undocumented code. I
would prefer smaller, iterative patches that contain testcases to
verify functionality.
- It still uses static singletons which are anathema to SCA (and
Tuscany) being based on IoC.
Given the vast amount of work ahead of us, could we start with
defining our objectives for WSDL loading and then define an interface
for retrieving WSDL artifacts, potentially using Celtix's WSDLManager
for ideas. From there, we can figure out how to best implement it?
Jim
As an implementation strategy
On Sep 18, 2006, at 11:26 AM, Yang ZHONG wrote:
> Thank you all for the patience.
> (I also used the waiting time to assure no huge change to the API
> and SPI)
>
> A Reference Implementation is now available at
> http://issues.apache.org/jira/secure/attachment/12341070/
> registry4.zip
> for JIRA
> http://issues.apache.org/jira/browse/TUSCANY-677
>
> The implementation has a JavaDoc at
> impl/SPI/doc
> and please try the live demo at
> impl/API/src/test/java/org/apache/tuscany/registry/test
> demonstrating using SPI to register Locator and loader and using
> API to get
> symbol on demand.
>
> A WSDL Reference Implementation will be provided next time.
>
> --
>
> Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Yang ZHONG <le...@gmail.com>.
Thank you all for the patience.
(I also used the waiting time to assure no huge change to the API and SPI)
A Reference Implementation is now available at
http://issues.apache.org/jira/secure/attachment/12341070/registry4.zip
for JIRA
http://issues.apache.org/jira/browse/TUSCANY-677
The implementation has a JavaDoc at
impl/SPI/doc
and please try the live demo at
impl/API/src/test/java/org/apache/tuscany/registry/test
demonstrating using SPI to register Locator and loader and using API to get
symbol on demand.
A WSDL Reference Implementation will be provided next time.
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Yang ZHONG <le...@gmail.com>.
Frank and I talked about the registry the other day,
we both think it may be something useful for SDO Type registry (and Global
Property registry).
(Did you suggest that too?)
However, there's no concrete plan to integrate yet.
By the time we actually integrate (if it happens), maybe SDO impl is moving
to Java 5 I hope :-)
Otherwise, I can volunteer myself again for the porting.
BTW, many products including Application Servers has moved to Java 5, they
enable standalone usage of the registry.
Otherwise, I can also volunteer myself again for the porting.
On 9/11/06, Fuhwei Lwo <fu...@bricemedia.com> wrote:
>
> Hi Yang,
>
> I took a review of your prototype and found you are implementing it
> in Java 5 SDK. Currently SDO impl is on JDK 1.4. Do you plan to
> support JDK 1.4 for this registry feature? Thanks.
>
> Fuhwei
>
> Yang ZHONG <le...@gmail.com> wrote: I've updated the
> registry proposal basing on Jim's feedback especially his
> wonderful runtime-pick-scope idea.
> Please see the new attachment at
> http://issues.apache.org/jira/secure/attachment/12340483/registry3.zip
> for JIRA
> http://issues.apache.org/jira/browse/TUSCANY-677
>
> Thanks, Jim.
>
> For your convenience, here copys some package description from the
> included
> JavaDoc
> (Still the included ReadMe.txt may help you find corresponding info)
>
> 1. Accessing the registry service
>
> WSDLRegistries WSDL;
>
> @Autowire
> public setWSDLRegistries(WSDLRegistries registries)
> {
> WSDL = registries;
> }
>
> 2. Accessing Definition identified by Name Space
>
> Definition myDefinition = WSDL.getDefinition( "
> http://incubator.apache.org/tuscany");
>
> --
>
> Yang ZHONG
>
>
>
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Fuhwei Lwo <fu...@bricemedia.com>.
Hi Yang,
I took a review of your prototype and found you are implementing it in Java 5 SDK. Currently SDO impl is on JDK 1.4. Do you plan to support JDK 1.4 for this registry feature? Thanks.
Fuhwei
Yang ZHONG <le...@gmail.com> wrote: I've updated the registry proposal basing on Jim's feedback especially his
wonderful runtime-pick-scope idea.
Please see the new attachment at
http://issues.apache.org/jira/secure/attachment/12340483/registry3.zip
for JIRA
http://issues.apache.org/jira/browse/TUSCANY-677
Thanks, Jim.
For your convenience, here copys some package description from the included
JavaDoc
(Still the included ReadMe.txt may help you find corresponding info)
1. Accessing the registry service
WSDLRegistries WSDL;
@Autowire
public setWSDLRegistries(WSDLRegistries registries)
{
WSDL = registries;
}
2. Accessing Definition identified by Name Space
Definition myDefinition = WSDL.getDefinition( "
http://incubator.apache.org/tuscany");
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Yang ZHONG <le...@gmail.com>.
I've updated the registry proposal basing on Jim's feedback especially his
wonderful runtime-pick-scope idea.
Please see the new attachment at
http://issues.apache.org/jira/secure/attachment/12340483/registry3.zip
for JIRA
http://issues.apache.org/jira/browse/TUSCANY-677
Thanks, Jim.
For your convenience, here copys some package description from the included
JavaDoc
(Still the included ReadMe.txt may help you find corresponding info)
1. Accessing the registry service
WSDLRegistries WSDL;
@Autowire
public setWSDLRegistries(WSDLRegistries registries)
{
WSDL = registries;
}
2. Accessing Definition identified by Name Space
Definition myDefinition = WSDL.getDefinition( "
http://incubator.apache.org/tuscany");
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Yang ZHONG <le...@gmail.com>.
ok, I'll propose a WSDL API similar to Celtix.
On 9/5/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Sep 5, 2006, at 11:22 AM, Yang ZHONG wrote:
>
> >
> > I've proposed hosting the registry dircetly under tuscany/java:
> > distribution
> > *registry*
> > sdo
> > spec
> > sca
> > The rational is we are dealing with generic issues beyond just sca
> > and sdo
> > anyway,
> > especially I know some SDO implementations are using registry for
> > types (and
> > elements).
> > There's one thing I don't even have preference myself at all: where
> > to host
> > the tailoring for sca.
> > It can either be
> > tuscany/java/registry/sca
> > or
> > tuscany/java/sca/registry
> Can we first try and solve the specific issue of WSDL loading and
> then see if we can make something generic? It feels as if a "one-size-
> fits-all" approach is going to introduce complexity we don't need in
> the SCA runtime. Also, doing this potentially introduces dependencies
> between the projects which was what we just eliminated and which I
> would not want to reintroduce.
>
> >>
> >> > - It also seems a lot of inner interfaces are used. I think things
> >> >> could be simplified by not using inner interfaces at all, possibly
> >> >> segregating classes using subpackages if necessary.
> >> >
> >> >
> >> > Some people find inner interface helpful and better readable,
> >> > I think the Java spec wouldn't include it if it's a absolute
> >> evil :-)
> >> <rant>I think statics on interfaces like .INSTANCE are evil.
> >> Thankfully, they are not widely used in Java technologies I am aware
> >> of (outside SDO and EMF) as they cause so many problems in managed
> >> environments where classloader isolation is important. ;-) I honestly
> >> don't understand how this pattern is easier to use as there are
> >> simple alternatives Java developers are familiar with such as IoC and
> >> factories. </rant>
> >
> >
> > The above paragraph was talking about inner interface, *not*
> > singleton.
> > I understand singleton causes management difficulties although it
> > makes
> > simplest/easiest Programming Model.
> > There's no singleton in API and WSDL API already.
> > I don't see you say inner interfaces are evil, however I can guess
> > they're
> > not your preference and I sure will replace them in API and SPI.
> >
> Sorry to be so adamant but static references to implementation
> classes on interfaces have caused me a lot of grief in the past. On
> the "inner" interface issue I think it is more common to use Java
> packages, so thanks for accommodating this.
> >
> >
> > Brilliant idea! Using the WSDL API as example, we can offer
> > definition/message/portType/binding/service Registry
> > directly to SCA contained component exactly the way you mentioned,
> > and offer scope aware WSDLRegistries to non SCA-contained or low/
> > system
> > level programming.
> >
> I think we can simplify this even further: we just offer a WSDL
> registry that is held in the DeploymentContext and thrown away after
> the deployment process. We don't need the registry to manage any
> scoping as that is done by the runtime. Jeremy suggested this a while
> back, I believe. In this case, we would have a loader that would
> process <import.wsdl> and create the registry if needed, putting it
> in the DeploymentContext. Subsequent requests would key off that. At
> the end of the deployment process, the DeploymentContext is thrown
> away so we don't have to worry about the cache managing references to
> classloaders or having to implement complex scoping algorithms.
>
> >> 3-3. message/portType/binding/service may not necessarily reside in
> >> > current
> >> > Definition, they may be available from included/delegated
> >> Definitions.
> >> > Without direct API to query message/portType/binding/service,
> >> > users
> >> > have to query current Definition first,
> >> > then manually and recursively query all included/delegated
> >> > Definitions,
> >> > which is quite error-prone..
> >> Could we provide a utility method or just modify the api to do this?
> >> Jervis or Dan, how does Celtix handle this?
> >> >
> >> As a way to move forward, do you think we could assume for the time
> >> being the runtime can handle resolving the correct registry instance
> >> and we take the Celtix API and merge it with the API you are
> >> proposing?
> >
> >
> > Are you fine/satisfied with the Celtix (WSDL) API? If so, I can put
> > a hold
> > on my efforts since I guess the Celtix (WSDL) API has an
> > implementation
> > already.
> > I remember someone mentioned a SCDL registry before. If you think
> > SCDL could
> > use a registry too, I can keep on the registry efforts.
> > Please let me know.
> I don't think we need a SCDL registry but I definitely think you
> should keep working on the WSDL registry since we do need one. I took
> Celtix as an example since it seemed intuitive. Perhaps a good way
> forward is to look at their API and make some of the modifications
> you suggested? Then, once we are satisfied with the API, we look at
> how to best implement it. I would start with the assumption that we
> just need a WSDL registry since I can't think of other model
> artifacts that need to be cached right now (there may be in the
> future but then we will have more use cases to work from). I'd also
> start with the assumption that scoping will be handled by the
> runtime, in this case the deployment context, and that model
> artifacts are thrown away after deployment and not used during
> invocation processing.
>
>
> Does this work?
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Jim Marino <jm...@myromatours.com>.
On Sep 5, 2006, at 11:22 AM, Yang ZHONG wrote:
>
> I've proposed hosting the registry dircetly under tuscany/java:
> distribution
> *registry*
> sdo
> spec
> sca
> The rational is we are dealing with generic issues beyond just sca
> and sdo
> anyway,
> especially I know some SDO implementations are using registry for
> types (and
> elements).
> There's one thing I don't even have preference myself at all: where
> to host
> the tailoring for sca.
> It can either be
> tuscany/java/registry/sca
> or
> tuscany/java/sca/registry
Can we first try and solve the specific issue of WSDL loading and
then see if we can make something generic? It feels as if a "one-size-
fits-all" approach is going to introduce complexity we don't need in
the SCA runtime. Also, doing this potentially introduces dependencies
between the projects which was what we just eliminated and which I
would not want to reintroduce.
>>
>> > - It also seems a lot of inner interfaces are used. I think things
>> >> could be simplified by not using inner interfaces at all, possibly
>> >> segregating classes using subpackages if necessary.
>> >
>> >
>> > Some people find inner interface helpful and better readable,
>> > I think the Java spec wouldn't include it if it's a absolute
>> evil :-)
>> <rant>I think statics on interfaces like .INSTANCE are evil.
>> Thankfully, they are not widely used in Java technologies I am aware
>> of (outside SDO and EMF) as they cause so many problems in managed
>> environments where classloader isolation is important. ;-) I honestly
>> don't understand how this pattern is easier to use as there are
>> simple alternatives Java developers are familiar with such as IoC and
>> factories. </rant>
>
>
> The above paragraph was talking about inner interface, *not*
> singleton.
> I understand singleton causes management difficulties although it
> makes
> simplest/easiest Programming Model.
> There's no singleton in API and WSDL API already.
> I don't see you say inner interfaces are evil, however I can guess
> they're
> not your preference and I sure will replace them in API and SPI.
>
Sorry to be so adamant but static references to implementation
classes on interfaces have caused me a lot of grief in the past. On
the "inner" interface issue I think it is more common to use Java
packages, so thanks for accommodating this.
>
>
> Brilliant idea! Using the WSDL API as example, we can offer
> definition/message/portType/binding/service Registry
> directly to SCA contained component exactly the way you mentioned,
> and offer scope aware WSDLRegistries to non SCA-contained or low/
> system
> level programming.
>
I think we can simplify this even further: we just offer a WSDL
registry that is held in the DeploymentContext and thrown away after
the deployment process. We don't need the registry to manage any
scoping as that is done by the runtime. Jeremy suggested this a while
back, I believe. In this case, we would have a loader that would
process <import.wsdl> and create the registry if needed, putting it
in the DeploymentContext. Subsequent requests would key off that. At
the end of the deployment process, the DeploymentContext is thrown
away so we don't have to worry about the cache managing references to
classloaders or having to implement complex scoping algorithms.
>> 3-3. message/portType/binding/service may not necessarily reside in
>> > current
>> > Definition, they may be available from included/delegated
>> Definitions.
>> > Without direct API to query message/portType/binding/service,
>> > users
>> > have to query current Definition first,
>> > then manually and recursively query all included/delegated
>> > Definitions,
>> > which is quite error-prone..
>> Could we provide a utility method or just modify the api to do this?
>> Jervis or Dan, how does Celtix handle this?
>> >
>> As a way to move forward, do you think we could assume for the time
>> being the runtime can handle resolving the correct registry instance
>> and we take the Celtix API and merge it with the API you are
>> proposing?
>
>
> Are you fine/satisfied with the Celtix (WSDL) API? If so, I can put
> a hold
> on my efforts since I guess the Celtix (WSDL) API has an
> implementation
> already.
> I remember someone mentioned a SCDL registry before. If you think
> SCDL could
> use a registry too, I can keep on the registry efforts.
> Please let me know.
I don't think we need a SCDL registry but I definitely think you
should keep working on the WSDL registry since we do need one. I took
Celtix as an example since it seemed intuitive. Perhaps a good way
forward is to look at their API and make some of the modifications
you suggested? Then, once we are satisfied with the API, we look at
how to best implement it. I would start with the assumption that we
just need a WSDL registry since I can't think of other model
artifacts that need to be cached right now (there may be in the
future but then we will have more use cases to work from). I'd also
start with the assumption that scoping will be handled by the
runtime, in this case the deployment context, and that model
artifacts are thrown away after deployment and not used during
invocation processing.
Does this work?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Yang ZHONG <le...@gmail.com>.
Thanks for your comments, and mine are inline below.
On 9/4/06, Jim Marino <jm...@myromatours.com> wrote:
>
> Hi Yang, comments inline.
>
> On Sep 4, 2006, at 12:14 PM, Yang ZHONG wrote:
>
> >
> > 2-1. SPI is not any part of user Programming Model at all, since it's
> > internal, we can change it any way later.
> >
> I'd prefer before we check something in and use it throughout the
> code base we sort these issues (SPI, API, WSDL) out as they will
> impact a number of bindings.
Fine with me, it's not a bad idea since we have to do it anyway and it saves
some (refactoring) time overall.
Sorry for folks waiting to wait a little longer.
> My current reference implementation has no dependency on SCA at
> > all, it
> > enables easy development, easy debuging and problems isolation.
> > Once the implementation is stabilized, we can always have more time
> > and
> > resources to refine what granularity to apply SCA.
> Where do we intend to house the code? If it is in the Java SCA
> project, I'd prefer we only have the capabilities we need and not
> build something that is a generic symbol cache. If the code will be
> maintained elsewhere, then I would tend to treat it as an external
> dependency.
I've proposed hosting the registry dircetly under tuscany/java:
distribution
*registry*
sdo
spec
sca
The rational is we are dealing with generic issues beyond just sca and sdo
anyway,
especially I know some SDO implementations are using registry for types (and
elements).
There's one thing I don't even have preference myself at all: where to host
the tailoring for sca.
It can either be
tuscany/java/registry/sca
or
tuscany/java/sca/registry
>
> > - It also seems a lot of inner interfaces are used. I think things
> >> could be simplified by not using inner interfaces at all, possibly
> >> segregating classes using subpackages if necessary.
> >
> >
> > Some people find inner interface helpful and better readable,
> > I think the Java spec wouldn't include it if it's a absolute evil :-)
> <rant>I think statics on interfaces like .INSTANCE are evil.
> Thankfully, they are not widely used in Java technologies I am aware
> of (outside SDO and EMF) as they cause so many problems in managed
> environments where classloader isolation is important. ;-) I honestly
> don't understand how this pattern is easier to use as there are
> simple alternatives Java developers are familiar with such as IoC and
> factories. </rant>
The above paragraph was talking about inner interface, *not* singleton.
I understand singleton causes management difficulties although it makes
simplest/easiest Programming Model.
There's no singleton in API and WSDL API already.
I don't see you say inner interfaces are evil, however I can guess they're
not your preference and I sure will replace them in API and SPI.
> An example of inner interface usage is EMF
> > interface EPackage
> > {
> > interface Registry
> > }
> > therefore EPackage.Registry is a Registry of EPackages.
> > I don't really normally argue about interface styles, I've already
> > changes
> > SymbolSpace.Registry to SymbolSpaceRegistry in the *new* attachment
> > as you
> > suggested before.
> > If you're talking about NameSpace.xxx, I sure will change them too
> > in next
> > update.
> Cool. Thanks.
> >
> > Right, I only documented non-SCA client Programming Model to use the
> > registry,
> > I hesitated to include SCA client one because of the requirement
> > (setRegistry) and the assumption of SCA clients know what to do.
> > Since you mention it (thank you), I'll also document the SCA client
> > PM to
> > use the registry in next update.
> >
> O.K., I think it is really simple:
>
> Registry registry;
>
> @Reference
> public void setRegistry(Registry registry){
>
> -or-
>
> @Autowire
> public void setRegistry(Registry registry){
Thanks a lot. I'll put them into JavaDoc.
>
> > If I understand correctly, you concern "why multiple dimensions".
> > A typical scenario is MyApplication.Ear = MyWeb.War + share.jar(
> > MyService.wsdl) + MyEJB.jar
> > and the share.jar is shared by both MyWeb and MyEJB.
> > Some frameworks has an option to check receiving data against
> > interface,
> > incuding Java and I know SCA used to have that option.
>
>
> > Checking instance against model may have problems if the model is
> > loaded as
> > more than one copies,
> > Xxx.class and SDO/EMF types all have such problems.
> >
> We don't keep the model around during runtime operation so I don't
> think this is a problem for us.
> > I don't know if current SCA ever computs equals, isSuperType and
> > instanceof
> > between message/portType/binding/service models.
> Even if we did do this, would it ever be done across remote
> boundaries (a deployment unit)? At that point we have by-val
> semantics (and likely serialization) anyway.
> > If never, I admit multi-dimension as a generic isuue doesn't have
> > to be
> > applied to SCA except for performance concerns
> > (I've seen real customers sometimes have huge WSDL/XSD files and
> > loading and
> > caching them more than once is unecessary pain for customers)
>
> Perhaps we can optimize as needed? If we cache per application, I
> don't see this as a huge performance hit. Also, I'd probably want
> things loaded separately in different deployment units as it
> simplifies re-deployment and application upgrades. So, I think
> caching per application and not multi-dimensionally should be the
> starting place.
Agree, let's "optimize as needed".
>
> > I see at least 3 areas WSDLManager can improve (besides the multi-
> > dimension
> > issue):
> > 3-1. It's nice the WSDLManager supports location(String/URL) Scoping.
> > however it doesn't seem supporting other Scoping such as
> > CompositeComponent
> > Particularly, it's a problem when wsdlLocation/scdlLocation is
> > absent
> > 3-2. Scope delegation is not mentioned at all. e.g. a location
> > query should
> > be able to be delegated to all included location,
> > and a CompositeComponent query should be able to be delegated
> > to all
> > included CompositeComponent
> Perhaps we can make this the job of the runtime? In other words, just
> as SCA does not require applications to track instances and has a
> concept of Scope, we could do the same for the registry. This would
> mean client code requests a registry from the runtime and the runtime
> resolves the correct one:
>
> @Autowire
> public void setRegistry(Registry registry){
>
> The runtime would "magically" return the correct instance. The client
> would never have to pass a Scope key to the registry. There are a
> number of ways this could be done. Jeremy has suggested one in the
> past using property factories (Jeremy, care to elaborate)? I've also
> toyed with the idea of "application scoped" system components.
Brilliant idea! Using the WSDL API as example, we can offer
definition/message/portType/binding/service Registry
directly to SCA contained component exactly the way you mentioned,
and offer scope aware WSDLRegistries to non SCA-contained or low/system
level programming.
> 3-3. message/portType/binding/service may not necessarily reside in
> > current
> > Definition, they may be available from included/delegated Definitions.
> > Without direct API to query message/portType/binding/service,
> > users
> > have to query current Definition first,
> > then manually and recursively query all included/delegated
> > Definitions,
> > which is quite error-prone..
> Could we provide a utility method or just modify the api to do this?
> Jervis or Dan, how does Celtix handle this?
> >
> As a way to move forward, do you think we could assume for the time
> being the runtime can handle resolving the correct registry instance
> and we take the Celtix API and merge it with the API you are proposing?
Are you fine/satisfied with the Celtix (WSDL) API? If so, I can put a hold
on my efforts since I guess the Celtix (WSDL) API has an implementation
already.
I remember someone mentioned a SCDL registry before. If you think SCDL could
use a registry too, I can keep on the registry efforts.
Please let me know.
Jim
>
>
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Jim Marino <jm...@myromatours.com>.
Hi Yang, comments inline.
On Sep 4, 2006, at 12:14 PM, Yang ZHONG wrote:
>
> 2-1. SPI is not any part of user Programming Model at all, since it's
> internal, we can change it any way later.
>
I'd prefer before we check something in and use it throughout the
code base we sort these issues (SPI, API, WSDL) out as they will
impact a number of bindings.
> My current reference implementation has no dependency on SCA at
> all, it
> enables easy development, easy debuging and problems isolation.
> Once the implementation is stabilized, we can always have more time
> and
> resources to refine what granularity to apply SCA.
Where do we intend to house the code? If it is in the Java SCA
project, I'd prefer we only have the capabilities we need and not
build something that is a generic symbol cache. If the code will be
maintained elsewhere, then I would tend to treat it as an external
dependency.
>
> - It also seems a lot of inner interfaces are used. I think things
>> could be simplified by not using inner interfaces at all, possibly
>> segregating classes using subpackages if necessary.
>
>
> Some people find inner interface helpful and better readable,
> I think the Java spec wouldn't include it if it's a absolute evil :-)
<rant>I think statics on interfaces like .INSTANCE are evil.
Thankfully, they are not widely used in Java technologies I am aware
of (outside SDO and EMF) as they cause so many problems in managed
environments where classloader isolation is important. ;-) I honestly
don't understand how this pattern is easier to use as there are
simple alternatives Java developers are familiar with such as IoC and
factories. </rant>
> An example of inner interface usage is EMF
> interface EPackage
> {
> interface Registry
> }
> therefore EPackage.Registry is a Registry of EPackages.
> I don't really normally argue about interface styles, I've already
> changes
> SymbolSpace.Registry to SymbolSpaceRegistry in the *new* attachment
> as you
> suggested before.
> If you're talking about NameSpace.xxx, I sure will change them too
> in next
> update.
Cool. Thanks.
>
> Right, I only documented non-SCA client Programming Model to use the
> registry,
> I hesitated to include SCA client one because of the requirement
> (setRegistry) and the assumption of SCA clients know what to do.
> Since you mention it (thank you), I'll also document the SCA client
> PM to
> use the registry in next update.
>
O.K., I think it is really simple:
Registry registry;
@Reference
public void setRegistry(Registry registry){
-or-
@Autowire
public void setRegistry(Registry registry){
>
> If I understand correctly, you concern "why multiple dimensions".
> A typical scenario is MyApplication.Ear = MyWeb.War + share.jar(
> MyService.wsdl) + MyEJB.jar
> and the share.jar is shared by both MyWeb and MyEJB.
> Some frameworks has an option to check receiving data against
> interface,
> incuding Java and I know SCA used to have that option.
> Checking instance against model may have problems if the model is
> loaded as
> more than one copies,
> Xxx.class and SDO/EMF types all have such problems.
>
We don't keep the model around during runtime operation so I don't
think this is a problem for us.
> I don't know if current SCA ever computs equals, isSuperType and
> instanceof
> between message/portType/binding/service models.
Even if we did do this, would it ever be done across remote
boundaries (a deployment unit)? At that point we have by-val
semantics (and likely serialization) anyway.
> If never, I admit multi-dimension as a generic isuue doesn't have
> to be
> applied to SCA except for performance concerns
> (I've seen real customers sometimes have huge WSDL/XSD files and
> loading and
> caching them more than once is unecessary pain for customers)
Perhaps we can optimize as needed? If we cache per application, I
don't see this as a huge performance hit. Also, I'd probably want
things loaded separately in different deployment units as it
simplifies re-deployment and application upgrades. So, I think
caching per application and not multi-dimensionally should be the
starting place.
>
> I see at least 3 areas WSDLManager can improve (besides the multi-
> dimension
> issue):
> 3-1. It's nice the WSDLManager supports location(String/URL) Scoping.
> however it doesn't seem supporting other Scoping such as
> CompositeComponent
> Particularly, it's a problem when wsdlLocation/scdlLocation is
> absent
> 3-2. Scope delegation is not mentioned at all. e.g. a location
> query should
> be able to be delegated to all included location,
> and a CompositeComponent query should be able to be delegated
> to all
> included CompositeComponent
Perhaps we can make this the job of the runtime? In other words, just
as SCA does not require applications to track instances and has a
concept of Scope, we could do the same for the registry. This would
mean client code requests a registry from the runtime and the runtime
resolves the correct one:
@Autowire
public void setRegistry(Registry registry){
The runtime would "magically" return the correct instance. The client
would never have to pass a Scope key to the registry. There are a
number of ways this could be done. Jeremy has suggested one in the
past using property factories (Jeremy, care to elaborate)? I've also
toyed with the idea of "application scoped" system components.
> 3-3. message/portType/binding/service may not necessarily reside in
> current
> Definition, they may be available from included/delegated Definitions.
> Without direct API to query message/portType/binding/service,
> users
> have to query current Definition first,
> then manually and recursively query all included/delegated
> Definitions,
> which is quite error-prone..
Could we provide a utility method or just modify the api to do this?
Jervis or Dan, how does Celtix handle this?
>
As a way to move forward, do you think we could assume for the time
being the runtime can handle resolving the correct registry instance
and we take the Celtix API and merge it with the API you are proposing?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Yang ZHONG <le...@gmail.com>.
Really appreciate your compliment and thanks a lot for your comments.
My comments are below.
On 9/3/06, Jim Marino <jm...@myromatours.com> wrote:
>
> Hi Yang,
>
> Thanks for your effort on this (the documentation is really
> impressive too). I have some more comments based on an initial look:
>
> - There appears to be a number of places static references on
> interfaces are used, e.g. SymbolSpace.Registry. Doing this is really
> problematic in a managed environment as we have found with SDO and
> earlier versions of SCA which used .INSTANCE. As a Java developer I
> also find this approach not really intuitive. Is there a technical
> reason for doing this?
Maybe the old attachment is confusing, I tried to remove it however I didn't
find a way to do that.
In the new attachment, I've already removed INSTANCE from API, and there's
no INSTANCE in WSDL API.
If you meant SPI, I didn't feel urgent to change right now from two
perspective:
2-1. SPI is not any part of user Programming Model at all, since it's
internal, we can change it any way later.
I intend to focus on API, WSDL API and reference implementations so
that Ant and other folks can use as soon as possible.
Then we can do fine tuning inside the implementations. So I
prioritize SPI changes lower/later than providing something working first.
2-2. There's a granularity to apply SCA. I'm pretty sure about two extremes:
SCA is perfect for service invocation and SCA is not a replacement
for basic programming such as "new ArrayList()".
For granularities between those two extremes, different people may
have different opinions.
So I prioritize SPI changes lower/later than providing API, WSDL API
and something working first.
My current reference implementation has no dependency on SCA at all, it
enables easy development, easy debuging and problems isolation.
Once the implementation is stabilized, we can always have more time and
resources to refine what granularity to apply SCA.
- It also seems a lot of inner interfaces are used. I think things
> could be simplified by not using inner interfaces at all, possibly
> segregating classes using subpackages if necessary.
Some people find inner interface helpful and better readable,
I think the Java spec wouldn't include it if it's a absolute evil :-)
An example of inner interface usage is EMF
interface EPackage
{
interface Registry
}
therefore EPackage.Registry is a Registry of EPackages.
I don't really normally argue about interface styles, I've already changes
SymbolSpace.Registry to SymbolSpaceRegistry in the *new* attachment as you
suggested before.
If you're talking about NameSpace.xxx, I sure will change them too in next
update.
- I don't think we should hardcode component names into interfaces
> nor do we need to use locateService() to find a component. Rather, we
> should just rely on the container to inject the correct regsitry
> instance through autowire into a component as in:
>
> @Autowire
> public void setRegistry(Registry myRegistry){
> //
> }
Right, I only documented non-SCA client Programming Model to use the
registry,
I hesitated to include SCA client one because of the requirement
(setRegistry) and the assumption of SCA clients know what to do.
Since you mention it (thank you), I'll also document the SCA client PM to
use the registry in next update.
Stepping back a bit, I would also like to understand the requirements
> of the registry a little better and this is where my ignorance of
> WSDL issues will probably show through...Do we need the ability to
> cache using multidimensional keys? For example, if we didn't share
> symbols across applications, I don't see that as a major performance
> issue given the number of WSDLs and applications a typical runtime
> instance is going to manage (limited) versus everything else that is
> going on including creation of the assembly model and runtime
> artifacts (many). Instead, couldn't we just cache by deployed unit?
If I understand correctly, you concern "why multiple dimensions".
A typical scenario is MyApplication.Ear = MyWeb.War + share.jar(
MyService.wsdl) + MyEJB.jar
and the share.jar is shared by both MyWeb and MyEJB.
Some frameworks has an option to check receiving data against interface,
incuding Java and I know SCA used to have that option.
Checking instance against model may have problems if the model is loaded as
more than one copies,
Xxx.class and SDO/EMF types all have such problems.
I don't know if current SCA ever computs equals, isSuperType and instanceof
between message/portType/binding/service models.
If never, I admit multi-dimension as a generic isuue doesn't have to be
applied to SCA except for performance concerns
(I've seen real customers sometimes have huge WSDL/XSD files and loading and
caching them more than once is unecessary pain for customers)
To help me understand things a bit better, why would a registry
> interface like the one below not work for our purposes (let's assume
> for the time being the container can provide the client code with the
> correct manager instance scoped to a deployment unit/classloader)?
>
> http://celtix.objectweb.org/docs/api/org/objectweb/celtix/wsdl/
> WSDLManager.html
I see at least 3 areas WSDLManager can improve (besides the multi-dimension
issue):
3-1. It's nice the WSDLManager supports location(String/URL) Scoping.
however it doesn't seem supporting other Scoping such as
CompositeComponent
Particularly, it's a problem when wsdlLocation/scdlLocation is absent
3-2. Scope delegation is not mentioned at all. e.g. a location query should
be able to be delegated to all included location,
and a CompositeComponent query should be able to be delegated to all
included CompositeComponent
3-3. message/portType/binding/service may not necessarily reside in current
Definition, they may be available from included/delegated Definitions.
Without direct API to query message/portType/binding/service, users
have to query current Definition first,
then manually and recursively query all included/delegated
Definitions,
which is quite error-prone..
Again, thanks for all your effort.
>
> Jim
Thank *you* for supporting the effort along the way.
On Sep 2, 2006, at 12:28 PM, Yang ZHONG wrote:
>
> > I've updated the registry proposal basing on feedbacks (thank everyone
> > especially Jeremy and Jim) and some time to refine diagrams and
> > examples/samples,
> > and proposed a WSDL Registry (thank Jeremy for strong-interface
> > suggestion).
> > Please see the new attachment at
> > http://issues.apache.org/jira/secure/attachment/12340097/registry.zip
> > for JIRA
> > http://issues.apache.org/jira/browse/TUSCANY-677
> >
> > It seemed easy to overlook ReadMe.txt and miss some info already
> > provided,
> > so please spend a little time on diagrams and examples/samples if
> > possible.
> >
> > The major change is the API Programming Model from
> > SymbolSpace.Registry.INSTANCE
> > to
> > CurrentCompositeContext.getContext().locateService(
> > SymbolSpaceRegistry.class, SymbolSpaceRegistry.SERVICE)
> > Thank Ant for detailed info.
> >
> > I've tried not to involve Scoping in the WSDL Registry, so the API
> > doesn't
> > mention Scoping at all.
> > However, a "scope" notation is still used in WSDLRegistry to make
> > the API
> > practically useful.
> > But I've left the signature to be "Object" to be flexible/open enough.
> > Although the WSDL Registry proposal doesn't cover Scoping, it's not
> > really
> > necessarily too early to discuss Scoping,
> > so that we might have a little bit more thorough thinking/
> > discussion about
> > Scoping before the eventual approach adopting.
> >
> > I see at least 3 kinds of scenario (examples assume WSDLRegistries
> > WSDL =
> > CurrentCompositeContext.getContext().locateService
> > ( WSDLRegistries.class,
> > WSDLRegistries.SERVICE)):
> >
> > 3-1. Designated WSDL location.
> > Users may need Message/PortType/Binding/Service/Definition lookup
> > to be
> > scoped by the designated location,
> > and recursively delegated to all included locations. e.g. (location
> > dimension/Scoping)
> > WSDL.getInterfaceRegistry(
> > FTP://hosting.org/WSDL/vertical.wsdl<ftp://hosting.org/WSDL/
> > vertical.wsdl>
> > )
> >
> > 3-2. Absent WSDL location with designated CompositeComponent (thank
> > Raymond
> > for explaining me Composite).
> > Users may need Message/PortType/Binding/Service/Definition lookup
> > to be
> > scoped by the designated CompositeComponent,
> > and recursively delegated to all included CompositeComponents. e.g.
> > (CompositeComponent Scoping)
> > WSDL.getBindingRegistry( compositeComponent)
> >
> > 3-3. Nothing designated.
> > Users may need Message/PortType/Binding/Service/Definition lookup
> > to be
> > scoped by context.
> > I don't know SCA confident enough yet to propose anything, however
> > I hope
> > you don't mind me sharing that I feel CompositeComponent is a natural
> > context Scoping for SCA.
> > If that's the approach adopted, the lookup may need to be scoped by
> > the
> > context CompositeComponent and recursively delegated to all included
> > CompositeComponents. e.g. (no matter what context Scoping ends up
> > being
> > adopted)
> > WSDL.getServiceRegistry( null)
> >
> > For either 3-2 or 3-3, we may need something like:
> > static Scoping COMPOSITE_SCOPING = new Scoping<CompositeComponent>()
> > {
> > public Iterable<CompositeComponent> includes (CompositeComponent
> > composite)
> > {
> > return composite.getIncludes().values();
> > }
> > public Iterable<CompositeComponent> imports (CompositeComponent
> > composite)
> > {
> > return composite.getImports().values();
> > }
> > };
> >
> >
> > --
> >
> > Yang ZHONG
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Jim Marino <jm...@myromatours.com>.
Hi Yang,
Thanks for your effort on this (the documentation is really
impressive too). I have some more comments based on an initial look:
- There appears to be a number of places static references on
interfaces are used, e.g. SymbolSpace.Registry. Doing this is really
problematic in a managed environment as we have found with SDO and
earlier versions of SCA which used .INSTANCE. As a Java developer I
also find this approach not really intuitive. Is there a technical
reason for doing this?
- It also seems a lot of inner interfaces are used. I think things
could be simplified by not using inner interfaces at all, possibly
segregating classes using subpackages if necessary.
- I don't think we should hardcode component names into interfaces
nor do we need to use locateService() to find a component. Rather, we
should just rely on the container to inject the correct regsitry
instance through autowire into a component as in:
@Autowire
public void setRegistry(Registry myRegistry){
//
}
Stepping back a bit, I would also like to understand the requirements
of the registry a little better and this is where my ignorance of
WSDL issues will probably show through...Do we need the ability to
cache using multidimensional keys? For example, if we didn't share
symbols across applications, I don't see that as a major performance
issue given the number of WSDLs and applications a typical runtime
instance is going to manage (limited) versus everything else that is
going on including creation of the assembly model and runtime
artifacts (many). Instead, couldn't we just cache by deployed unit?
To help me understand things a bit better, why would a registry
interface like the one below not work for our purposes (let's assume
for the time being the container can provide the client code with the
correct manager instance scoped to a deployment unit/classloader)?
http://celtix.objectweb.org/docs/api/org/objectweb/celtix/wsdl/
WSDLManager.html
Again, thanks for all your effort.
Jim
On Sep 2, 2006, at 12:28 PM, Yang ZHONG wrote:
> I've updated the registry proposal basing on feedbacks (thank everyone
> especially Jeremy and Jim) and some time to refine diagrams and
> examples/samples,
> and proposed a WSDL Registry (thank Jeremy for strong-interface
> suggestion).
> Please see the new attachment at
> http://issues.apache.org/jira/secure/attachment/12340097/registry.zip
> for JIRA
> http://issues.apache.org/jira/browse/TUSCANY-677
>
> It seemed easy to overlook ReadMe.txt and miss some info already
> provided,
> so please spend a little time on diagrams and examples/samples if
> possible.
>
> The major change is the API Programming Model from
> SymbolSpace.Registry.INSTANCE
> to
> CurrentCompositeContext.getContext().locateService(
> SymbolSpaceRegistry.class, SymbolSpaceRegistry.SERVICE)
> Thank Ant for detailed info.
>
> I've tried not to involve Scoping in the WSDL Registry, so the API
> doesn't
> mention Scoping at all.
> However, a "scope" notation is still used in WSDLRegistry to make
> the API
> practically useful.
> But I've left the signature to be "Object" to be flexible/open enough.
> Although the WSDL Registry proposal doesn't cover Scoping, it's not
> really
> necessarily too early to discuss Scoping,
> so that we might have a little bit more thorough thinking/
> discussion about
> Scoping before the eventual approach adopting.
>
> I see at least 3 kinds of scenario (examples assume WSDLRegistries
> WSDL =
> CurrentCompositeContext.getContext().locateService
> ( WSDLRegistries.class,
> WSDLRegistries.SERVICE)):
>
> 3-1. Designated WSDL location.
> Users may need Message/PortType/Binding/Service/Definition lookup
> to be
> scoped by the designated location,
> and recursively delegated to all included locations. e.g. (location
> dimension/Scoping)
> WSDL.getInterfaceRegistry(
> FTP://hosting.org/WSDL/vertical.wsdl<ftp://hosting.org/WSDL/
> vertical.wsdl>
> )
>
> 3-2. Absent WSDL location with designated CompositeComponent (thank
> Raymond
> for explaining me Composite).
> Users may need Message/PortType/Binding/Service/Definition lookup
> to be
> scoped by the designated CompositeComponent,
> and recursively delegated to all included CompositeComponents. e.g.
> (CompositeComponent Scoping)
> WSDL.getBindingRegistry( compositeComponent)
>
> 3-3. Nothing designated.
> Users may need Message/PortType/Binding/Service/Definition lookup
> to be
> scoped by context.
> I don't know SCA confident enough yet to propose anything, however
> I hope
> you don't mind me sharing that I feel CompositeComponent is a natural
> context Scoping for SCA.
> If that's the approach adopted, the lookup may need to be scoped by
> the
> context CompositeComponent and recursively delegated to all included
> CompositeComponents. e.g. (no matter what context Scoping ends up
> being
> adopted)
> WSDL.getServiceRegistry( null)
>
> For either 3-2 or 3-3, we may need something like:
> static Scoping COMPOSITE_SCOPING = new Scoping<CompositeComponent>()
> {
> public Iterable<CompositeComponent> includes (CompositeComponent
> composite)
> {
> return composite.getIncludes().values();
> }
> public Iterable<CompositeComponent> imports (CompositeComponent
> composite)
> {
> return composite.getImports().values();
> }
> };
>
>
> --
>
> Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Yang ZHONG <le...@gmail.com>.
I've updated the registry proposal basing on feedbacks (thank everyone
especially Jeremy and Jim) and some time to refine diagrams and
examples/samples,
and proposed a WSDL Registry (thank Jeremy for strong-interface suggestion).
Please see the new attachment at
http://issues.apache.org/jira/secure/attachment/12340097/registry.zip
for JIRA
http://issues.apache.org/jira/browse/TUSCANY-677
It seemed easy to overlook ReadMe.txt and miss some info already provided,
so please spend a little time on diagrams and examples/samples if possible.
The major change is the API Programming Model from
SymbolSpace.Registry.INSTANCE
to
CurrentCompositeContext.getContext().locateService(
SymbolSpaceRegistry.class, SymbolSpaceRegistry.SERVICE)
Thank Ant for detailed info.
I've tried not to involve Scoping in the WSDL Registry, so the API doesn't
mention Scoping at all.
However, a "scope" notation is still used in WSDLRegistry to make the API
practically useful.
But I've left the signature to be "Object" to be flexible/open enough.
Although the WSDL Registry proposal doesn't cover Scoping, it's not really
necessarily too early to discuss Scoping,
so that we might have a little bit more thorough thinking/discussion about
Scoping before the eventual approach adopting.
I see at least 3 kinds of scenario (examples assume WSDLRegistries WSDL =
CurrentCompositeContext.getContext().locateService( WSDLRegistries.class,
WSDLRegistries.SERVICE)):
3-1. Designated WSDL location.
Users may need Message/PortType/Binding/Service/Definition lookup to be
scoped by the designated location,
and recursively delegated to all included locations. e.g. (location
dimension/Scoping)
WSDL.getInterfaceRegistry(
FTP://hosting.org/WSDL/vertical.wsdl<ftp://hosting.org/WSDL/vertical.wsdl>
)
3-2. Absent WSDL location with designated CompositeComponent (thank Raymond
for explaining me Composite).
Users may need Message/PortType/Binding/Service/Definition lookup to be
scoped by the designated CompositeComponent,
and recursively delegated to all included CompositeComponents. e.g.
(CompositeComponent Scoping)
WSDL.getBindingRegistry( compositeComponent)
3-3. Nothing designated.
Users may need Message/PortType/Binding/Service/Definition lookup to be
scoped by context.
I don't know SCA confident enough yet to propose anything, however I hope
you don't mind me sharing that I feel CompositeComponent is a natural
context Scoping for SCA.
If that's the approach adopted, the lookup may need to be scoped by the
context CompositeComponent and recursively delegated to all included
CompositeComponents. e.g. (no matter what context Scoping ends up being
adopted)
WSDL.getServiceRegistry( null)
For either 3-2 or 3-3, we may need something like:
static Scoping COMPOSITE_SCOPING = new Scoping<CompositeComponent>()
{
public Iterable<CompositeComponent> includes (CompositeComponent
composite)
{
return composite.getIncludes().values();
}
public Iterable<CompositeComponent> imports (CompositeComponent
composite)
{
return composite.getImports().values();
}
};
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Jeremy Boynes <jb...@apache.org>.
On Aug 30, 2006, at 12:20 PM, Yang ZHONG wrote:
> No problem, consider them removed in API.
>
> Sorry, what's the WSDL model used in SCA again please?
We don't really model WSDL. We do parse it using WSDL4J for now but
need something to support WSDL2.0 (probably Woden when it can support
1.1).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Yang ZHONG <le...@gmail.com>.
No problem, consider them removed in API.
Sorry, what's the WSDL model used in SCA again please?
On 8/30/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Aug 30, 2006, at 11:59 AM, Yang ZHONG wrote:
>
> > Thank Ant so much for details, that's very helpful!
> >
> > I'll update the API:
> > 2-1. remove INSTANCE
> > 2-2. demonstrate the SCA way to get SymbolSpace.Registry
> > implementation in
> > JavaDoc
> >
> Why do we have the "inner" interface? I agree with Jeremy that it
> doesn't seem very intuitive.
>
> > SymbolSpace.Registry is the generic registry interface, it doesn't
> > prevent
> > us from having SCA specific interface(s).
> > I can come up with a WSDL Registry interface proposal. Can someone
> > tell me
> > which model is used by SCA: WST, WSDL4J, EMF, home grown or
> > anything else?
> >
> > On 8/30/06, Jeremy Boynes <jb...@apache.org> wrote:
> >>
> >> I'm having trouble parsing this. Are you talking about an SCA
> >> registry, or a WSDL registry, or the mechanism for locating it (via
> >> IoC as Ant described or something else)?
> >>
> >> I was saying that in an IoC world there is /no/ provider part of the
> >> API - a user never locates anything, they declare dependencies and
> >> the container resolves them. The dependency would be on the actual
> >> client interface (SymbolSpace.Registry I guess but I've already
> >> admitted to not grokking the interfaces).
> >>
> >> --
> >> Jeremy
> >>
> >> On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:
> >>
> >> > Can someone propose a SCA specific API mentioned by Jeremy please?
> >> > Something like
> >> > interface ScaRegistry
> >> > {
> >> > Definition getDefinition (String nameSpace);
> >> > Message getMessage (QName);
> >> > }
> >> > I don't know the SCA requirement much enough to make such proposal.
> >> >
> >> > At the same time, we can practise IoC in ScaRegistry service
> >> locating.
> >> > I hope I can learn from that practice and update the registry
> >> > generic API
> >> > accordingly.
> >> >
> >> > Thanks for pointing out a nice mechanism.
> >> >
> >> > On 8/30/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >>
> >> >>
> >> >> On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
> >> >>
> >> >> > As part of Tuscany there should not be any mechanism in a API
> >> for
> >> >> > "service location" - that is the responsibility of the IoC
> >> >> container.
> >> >> >
> >> >> +1 (which nicely avoids external dependencies on some locator
> >> >> implementation and evil Singletons)
> >> >>
> >> >> > --
> >> >> > Jeremy
> >> >> >
> >> >>
> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> >
> >> > Yang ZHONG
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
> >
> > --
> >
> > Yang ZHONG
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 30, 2006, at 11:59 AM, Yang ZHONG wrote:
> Thank Ant so much for details, that's very helpful!
>
> I'll update the API:
> 2-1. remove INSTANCE
> 2-2. demonstrate the SCA way to get SymbolSpace.Registry
> implementation in
> JavaDoc
>
Why do we have the "inner" interface? I agree with Jeremy that it
doesn't seem very intuitive.
> SymbolSpace.Registry is the generic registry interface, it doesn't
> prevent
> us from having SCA specific interface(s).
> I can come up with a WSDL Registry interface proposal. Can someone
> tell me
> which model is used by SCA: WST, WSDL4J, EMF, home grown or
> anything else?
>
> On 8/30/06, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> I'm having trouble parsing this. Are you talking about an SCA
>> registry, or a WSDL registry, or the mechanism for locating it (via
>> IoC as Ant described or something else)?
>>
>> I was saying that in an IoC world there is /no/ provider part of the
>> API - a user never locates anything, they declare dependencies and
>> the container resolves them. The dependency would be on the actual
>> client interface (SymbolSpace.Registry I guess but I've already
>> admitted to not grokking the interfaces).
>>
>> --
>> Jeremy
>>
>> On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:
>>
>> > Can someone propose a SCA specific API mentioned by Jeremy please?
>> > Something like
>> > interface ScaRegistry
>> > {
>> > Definition getDefinition (String nameSpace);
>> > Message getMessage (QName);
>> > }
>> > I don't know the SCA requirement much enough to make such proposal.
>> >
>> > At the same time, we can practise IoC in ScaRegistry service
>> locating.
>> > I hope I can learn from that practice and update the registry
>> > generic API
>> > accordingly.
>> >
>> > Thanks for pointing out a nice mechanism.
>> >
>> > On 8/30/06, Jim Marino <jm...@myromatours.com> wrote:
>> >>
>> >>
>> >> On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
>> >>
>> >> > As part of Tuscany there should not be any mechanism in a API
>> for
>> >> > "service location" - that is the responsibility of the IoC
>> >> container.
>> >> >
>> >> +1 (which nicely avoids external dependencies on some locator
>> >> implementation and evil Singletons)
>> >>
>> >> > --
>> >> > Jeremy
>> >> >
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> >
>> > Yang ZHONG
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
>
> Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Yang ZHONG <le...@gmail.com>.
Thank Ant so much for details, that's very helpful!
I'll update the API:
2-1. remove INSTANCE
2-2. demonstrate the SCA way to get SymbolSpace.Registry implementation in
JavaDoc
SymbolSpace.Registry is the generic registry interface, it doesn't prevent
us from having SCA specific interface(s).
I can come up with a WSDL Registry interface proposal. Can someone tell me
which model is used by SCA: WST, WSDL4J, EMF, home grown or anything else?
On 8/30/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> I'm having trouble parsing this. Are you talking about an SCA
> registry, or a WSDL registry, or the mechanism for locating it (via
> IoC as Ant described or something else)?
>
> I was saying that in an IoC world there is /no/ provider part of the
> API - a user never locates anything, they declare dependencies and
> the container resolves them. The dependency would be on the actual
> client interface (SymbolSpace.Registry I guess but I've already
> admitted to not grokking the interfaces).
>
> --
> Jeremy
>
> On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:
>
> > Can someone propose a SCA specific API mentioned by Jeremy please?
> > Something like
> > interface ScaRegistry
> > {
> > Definition getDefinition (String nameSpace);
> > Message getMessage (QName);
> > }
> > I don't know the SCA requirement much enough to make such proposal.
> >
> > At the same time, we can practise IoC in ScaRegistry service locating.
> > I hope I can learn from that practice and update the registry
> > generic API
> > accordingly.
> >
> > Thanks for pointing out a nice mechanism.
> >
> > On 8/30/06, Jim Marino <jm...@myromatours.com> wrote:
> >>
> >>
> >> On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
> >>
> >> > As part of Tuscany there should not be any mechanism in a API for
> >> > "service location" - that is the responsibility of the IoC
> >> container.
> >> >
> >> +1 (which nicely avoids external dependencies on some locator
> >> implementation and evil Singletons)
> >>
> >> > --
> >> > Jeremy
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
> >
> > --
> >
> > Yang ZHONG
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by ant elder <an...@gmail.com>.
In case its not completely clear from Jeremy and Jim's emails what to do:
you could define a client interface for the registry, write an
implementation of that and define that impl class name in some scdl. We can
then include the scdl in the runtime and things could use autowire to get
hold of the registry instance. As and example of this you can look at our
ServletHost, ServletHostImpl, how thats defined in the web app scdl, and
then how thats used by the Axis2 binding:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/spi/src/main/java/org/apache/tuscany/spi/host/ServletHost.java
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/runtime/webapp-host/src/main/java/org/apache/tuscany/runtime/webapp/ServletHostImpl.java
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/runtime/webapp-host/src/main/resources/META-INF/sca/webapp.system.scdl
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.axis2/src/main/java/org/apache/tuscany/binding/axis2/Axis2BindingBuilder.java
...ant
On 8/30/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
>
> > As part of Tuscany there should not be any mechanism in a API for
> > "service location" - that is the responsibility of the IoC container.
> >
> +1 (which nicely avoids external dependencies on some locator
> implementation and evil Singletons)
>
> > --
> > Jeremy
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Jeremy Boynes <jb...@apache.org>.
I'm having trouble parsing this. Are you talking about an SCA
registry, or a WSDL registry, or the mechanism for locating it (via
IoC as Ant described or something else)?
I was saying that in an IoC world there is /no/ provider part of the
API - a user never locates anything, they declare dependencies and
the container resolves them. The dependency would be on the actual
client interface (SymbolSpace.Registry I guess but I've already
admitted to not grokking the interfaces).
--
Jeremy
On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:
> Can someone propose a SCA specific API mentioned by Jeremy please?
> Something like
> interface ScaRegistry
> {
> Definition getDefinition (String nameSpace);
> Message getMessage (QName);
> }
> I don't know the SCA requirement much enough to make such proposal.
>
> At the same time, we can practise IoC in ScaRegistry service locating.
> I hope I can learn from that practice and update the registry
> generic API
> accordingly.
>
> Thanks for pointing out a nice mechanism.
>
> On 8/30/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>>
>> On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
>>
>> > As part of Tuscany there should not be any mechanism in a API for
>> > "service location" - that is the responsibility of the IoC
>> container.
>> >
>> +1 (which nicely avoids external dependencies on some locator
>> implementation and evil Singletons)
>>
>> > --
>> > Jeremy
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
>
> Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Yang ZHONG <le...@gmail.com>.
Can someone propose a SCA specific API mentioned by Jeremy please?
Something like
interface ScaRegistry
{
Definition getDefinition (String nameSpace);
Message getMessage (QName);
}
I don't know the SCA requirement much enough to make such proposal.
At the same time, we can practise IoC in ScaRegistry service locating.
I hope I can learn from that practice and update the registry generic API
accordingly.
Thanks for pointing out a nice mechanism.
On 8/30/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
>
> > As part of Tuscany there should not be any mechanism in a API for
> > "service location" - that is the responsibility of the IoC container.
> >
> +1 (which nicely avoids external dependencies on some locator
> implementation and evil Singletons)
>
> > --
> > Jeremy
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
> As part of Tuscany there should not be any mechanism in a API for
> "service location" - that is the responsibility of the IoC container.
>
+1 (which nicely avoids external dependencies on some locator
implementation and evil Singletons)
> --
> Jeremy
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Jeremy Boynes <jb...@apache.org>.
As part of Tuscany there should not be any mechanism in a API for
"service location" - that is the responsibility of the IoC container.
--
Jeremy
On Aug 30, 2006, at 10:43 AM, Yang ZHONG wrote:
> I'm fine with other service locating mechanisms, please name one
> and I'll
> update.
>
> Please keep little dependency. If the other mechanism(s) has
> dependency more
> than just J2SE such as SCA, JNDI repository,
> may be we can have several mechanism coexisted target various
> requirement...
>
> Thanks again for comments.
>
> On 8/30/06, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> I don't think we need "Provider" at all.
>> --
>> Jeremy
>>
>> On Aug 30, 2006, at 9:59 AM, Jim Marino wrote:
>>
>> > I had one additional comment: is there a reason we have to use the
>> > ".INSTANCE" approach to locating the default Provider?
>> >
>> > Jim
>> >
>> > On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
>> >
>> >> Raymond guessed right that it's an API/SPI review, so no impl/
>> >> tests attached
>> >> yet although I have some impl already.
>> >>
>> >> Ant guessed right too that I forgot to grant license, I must be
>> >> not thinking
>> >> straight working late :-)
>> >> I don't see any link to post-grant, I'll remember to do that for
>> >> following
>> >> attachments. Thank Ant.
>> >>
>> >> There's "neither* EMF *nor* Eclipse dependency. impl/EMF and impl/
>> >> Eclipse
>> >> are just subproject targeting certain usage.
>> >> Please take a look at ReadMe.txt for more details, it also have
>> >> info to find
>> >> Class Diagram and others.
>> >>
>> >> I agree with Jeremy that strongly-typed Maps/interfaces are
>> sometimes
>> >> preferred.
>> >> Actually, generalization and extensibility is exactly the selling
>> >> point of
>> >> this generic registry.
>> >> Tailoring can be done based on the framework/infrastructure/
>> >> fundation (as
>> >> Raymond commented).
>> >> There're at least two ways to provide strong interfaces over this
>> >> registry.
>> >> 2-1. Delegating
>> >> new StrongInterface()
>> >> {
>> >> public MySymbol getMySymbol (QName qName)
>> >> {
>> >> return mySymbolSpace.resolve( qName);
>> >> }
>> >> }
>> >> 2-2. Extending
>> >> class StrongInterfaceImpl extends SymbolSpaceImpl implement
>> >> StrongInterface
>> >>
>> >> Thank everyone for all comments.
>> >>
>> >> On 8/30/06, Raymond Feng <en...@gmail.com> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> Please see my comments in line.
>> >>>
>> >>> Thanks,
>> >>> Raymond
>> >>>
>> >>> ----- Original Message -----
>> >>> From: "Jeremy Boynes" <jb...@apache.org>
>> >>> To: <tu...@ws.apache.org>
>> >>> Sent: Wednesday, August 30, 2006 8:19 AM
>> >>> Subject: Registry proposal, was: Delivery Status Notification
>> >>> (Failure)
>> >>>
>> >>>
>> >>> >I might be missing something as well but I didn't see any code
>> >>> under impl
>> >>> >at all
>> >>>
>> >>> I guess it's for the API/SPI review first.
>> >>>
>> >>> >
>> >>> > I'm also with Ant in thinking we should not have a dependency
>> >>> on EMF.
>> >>> >
>> >>>
>> >>> From the javadoc, I don't see the EMF dependencies.
>> >>>
>> >>> > I'd also add that I found it difficult to grok the
>> >>> relationships between
>> >>> > all the interfaces and inner-interfaces and how the behaviour
>> >>> would
>> >>> > integrate with Map semantics - for example, how does this
>> >>> differ from
>> >>> > just using strongly-typed Maps?
>> >>>
>> >>> I agree. If the interface is designed for public API/SPI, it
>> >>> should be
>> >>> first-class interface instead of being inner.
>> >>>
>> >>> I'm also seeing a lot of naming conflicts among API and SPI
>> >>> interfaces/classes/parameterized types. This seems to be very
>> >>> problematic
>> >>> to
>> >>> me. When we run out of names, it means to me we don't model it
>> >>> correctly.
>> >>>
>> >>> A class diagram would be of great help for us.
>> >>>
>> >>> >
>> >>> > I'm also not convinced that throwing everything (all types of
>> >>> stuff) into
>> >>> > one central registry model is a good way to go. I can see a
>> >>> lot of
>> >>> > benefit in having more specialized interfaces tailored for
>> >>> each type of
>> >>> > stuff.
>> >>>
>> >>> I guess we can reuse the same infrastrcture backed by the generic
>> >>> registry
>> >>> but provide more specialized interfaces on top of it. And we can
>> >>> also
>> >>> choose
>> >>> to have separate instances of registries for specific domains.
>> >>>
>> >>> >
>> >>> > --
>> >>> > Jeremy
>> >>> >
>> >>> > On Aug 30, 2006, at 4:10 AM, ant elder wrote:
>> >>> >
>> >>> >> Having this attached to a JIRA is fine, thats preferred over
>> >>> sending
>> >>> >> attachments to the dev list.
>> >>> >>
>> >>> >> Thanks for all this, I've only just started looking but it
>> >>> looks very
>> >>> >> comprehensive, a lot more than I was expecting 8-). I've a
>> >>> few questions
>> >>> >> so
>> >>> >> far. Firstly you didn't click the button granting license of
>> >>> the code
>> >>> to
>> >>> >> the
>> >>> >> ASF, was that an oversight? The readme talks about some test
>> >>> examples
>> >>> >> and
>> >>> >> samples showing how to use the registry but the test folders
>> >>> don't seem
>> >>> >> to
>> >>> >> be included in the zip? From the brief look it wasn't clear to
>> >>> me if
>> >>> the
>> >>> >> registry will require EMF, hopefully it doesn't?
>> >>> >>
>> >>> >> Thanks,
>> >>> >>
>> >>> >> ...ant
>> >>> >>
>> >>> >> On 8/30/06, Yang ZHONG <le...@gmail.com> wrote:
>> >>> >>>
>> >>> >>> Neither tuscany-dev nor infra takes my email with attachment,
>> >>> so I've
>> >>> >>> attached file for review into
>> >>> >>> http://issues.apache.org/jira/browse/TUSCANY-677
>> >>> >>>
>> >>> >>> Sorry for the inconvenience and thanks for any comment.
>> >>> >>>
>> >>> >>> On 8/30/06, Mail Delivery Subsystem <mailer-
>> >>> daemon@googlemail.com>
>> >>> >>> wrote:
>> >>> >>> >
>> >>> >>> > This is an automatically generated Delivery Status
>> >>> Notification
>> >>> >>> >
>> >>> >>> > Delivery to the following recipient failed permanently:
>> >>> >>> >
>> >>> >>> > infra@ws.apache.org
>> >>> >>> >
>> >>> >>> > Technical details of permanent failure:
>> >>> >>> > PERM_FAILURE: SMTP Error (state 12): 552 Message rejected
>> >>> as it
>> >>> >>> is spam
>> >>> >>> > (body)
>> >>> >>> >
>> >>> >>> > ----- Original message -----
>> >>> >>> >
>> >>> >>> > Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
>> >>> >>> > Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
>> >>> >>> > Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006
>> 03:06:41
>> >>> >>> -0700
>> >>> >>> (PDT)
>> >>> >>> > Message-ID:
>> >>> >>> <eae0faaf0608300306v6906b61ey95e006083d681761@mail.gmail.com
>> >>> >>> >
>> >>> >>> > Date: Wed, 30 Aug 2006 03:06:41 -0700
>> >>> >>> > From: "Yang ZHONG" <le...@gmail.com>
>> >>> >>> > To: tuscany-dev@ws.apache.org
>> >>> >>> > Subject: Re: Auto discovering WSDL
>> >>> >>> > Cc: infra@ws.apache.org
>> >>> >>> > In-Reply-To:
>> >>> >>> <eae0faaf0608241438t9b8cb72s8b92051ef3d0173a@mail.gmail.com
>> >>> >>> >
>> >>> >>> > MIME-Version: 1.0
>> >>> >>> > Content-Type: multipart/mixed;
>> >>> >>> > boundary="----=_Part_28704_31437365.1156932401933"
>> >>> >>> > References: <
>> >>> >>> > 244F5835C09CB641AE1D928BB2B0B9D8021CCD17@amereast-
>> >>> >>> ems2.IONAGLOBAL.COM>
>> >>> >>> >
>> >>> >>> <ea...@mail.gmail.com>
>> >>> >>> >
>> >>> >>> <ea...@mail.gmail.com>
>> >>> >>> >
>> >>> >>> <71...@mail.gmail.com>
>> >>> >>> >
>> >>> >>> <ea...@mail.gmail.com>
>> >>> >>> >
>> >>> >>> > ------=_Part_28704_31437365.1156932401933
>> >>> >>> > Content-Type: multipart/alternative;
>> >>> >>> > boundary="----=_Part_28705_19724073.1156932401933"
>> >>> >>> >
>> >>> >>> > ------=_Part_28705_19724073.1156932401933
>> >>> >>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> >>> >>> > Content-Transfer-Encoding: 7bit
>> >>> >>> > Content-Disposition: inline
>> >>> >>> >
>> >>> >>> > Could you please review the registry API and SPI?
>> >>> >>> >
>> >>> >>> > ----- Message truncated -----
>> >>> >>> >
>> >>> >>> >
>> >>> >>>
>> >>> >>>
>> >>> >>> --
>> >>> >>>
>> >>> >>> Yang ZHONG
>> >>> >>>
>> >>> >>>
>> >>> >
>> >>> >
>> >>> >
>> >>>
>> --------------------------------------------------------------------
>> >>> -
>> >>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>> >
>> >>>
>> >>>
>> >>>
>> --------------------------------------------------------------------
>> >>> -
>> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >>
>> >> Yang ZHONG
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
>
> Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Yang ZHONG <le...@gmail.com>.
I'm fine with other service locating mechanisms, please name one and I'll
update.
Please keep little dependency. If the other mechanism(s) has dependency more
than just J2SE such as SCA, JNDI repository,
may be we can have several mechanism coexisted target various requirement...
Thanks again for comments.
On 8/30/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> I don't think we need "Provider" at all.
> --
> Jeremy
>
> On Aug 30, 2006, at 9:59 AM, Jim Marino wrote:
>
> > I had one additional comment: is there a reason we have to use the
> > ".INSTANCE" approach to locating the default Provider?
> >
> > Jim
> >
> > On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
> >
> >> Raymond guessed right that it's an API/SPI review, so no impl/
> >> tests attached
> >> yet although I have some impl already.
> >>
> >> Ant guessed right too that I forgot to grant license, I must be
> >> not thinking
> >> straight working late :-)
> >> I don't see any link to post-grant, I'll remember to do that for
> >> following
> >> attachments. Thank Ant.
> >>
> >> There's "neither* EMF *nor* Eclipse dependency. impl/EMF and impl/
> >> Eclipse
> >> are just subproject targeting certain usage.
> >> Please take a look at ReadMe.txt for more details, it also have
> >> info to find
> >> Class Diagram and others.
> >>
> >> I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
> >> preferred.
> >> Actually, generalization and extensibility is exactly the selling
> >> point of
> >> this generic registry.
> >> Tailoring can be done based on the framework/infrastructure/
> >> fundation (as
> >> Raymond commented).
> >> There're at least two ways to provide strong interfaces over this
> >> registry.
> >> 2-1. Delegating
> >> new StrongInterface()
> >> {
> >> public MySymbol getMySymbol (QName qName)
> >> {
> >> return mySymbolSpace.resolve( qName);
> >> }
> >> }
> >> 2-2. Extending
> >> class StrongInterfaceImpl extends SymbolSpaceImpl implement
> >> StrongInterface
> >>
> >> Thank everyone for all comments.
> >>
> >> On 8/30/06, Raymond Feng <en...@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Please see my comments in line.
> >>>
> >>> Thanks,
> >>> Raymond
> >>>
> >>> ----- Original Message -----
> >>> From: "Jeremy Boynes" <jb...@apache.org>
> >>> To: <tu...@ws.apache.org>
> >>> Sent: Wednesday, August 30, 2006 8:19 AM
> >>> Subject: Registry proposal, was: Delivery Status Notification
> >>> (Failure)
> >>>
> >>>
> >>> >I might be missing something as well but I didn't see any code
> >>> under impl
> >>> >at all
> >>>
> >>> I guess it's for the API/SPI review first.
> >>>
> >>> >
> >>> > I'm also with Ant in thinking we should not have a dependency
> >>> on EMF.
> >>> >
> >>>
> >>> From the javadoc, I don't see the EMF dependencies.
> >>>
> >>> > I'd also add that I found it difficult to grok the
> >>> relationships between
> >>> > all the interfaces and inner-interfaces and how the behaviour
> >>> would
> >>> > integrate with Map semantics - for example, how does this
> >>> differ from
> >>> > just using strongly-typed Maps?
> >>>
> >>> I agree. If the interface is designed for public API/SPI, it
> >>> should be
> >>> first-class interface instead of being inner.
> >>>
> >>> I'm also seeing a lot of naming conflicts among API and SPI
> >>> interfaces/classes/parameterized types. This seems to be very
> >>> problematic
> >>> to
> >>> me. When we run out of names, it means to me we don't model it
> >>> correctly.
> >>>
> >>> A class diagram would be of great help for us.
> >>>
> >>> >
> >>> > I'm also not convinced that throwing everything (all types of
> >>> stuff) into
> >>> > one central registry model is a good way to go. I can see a
> >>> lot of
> >>> > benefit in having more specialized interfaces tailored for
> >>> each type of
> >>> > stuff.
> >>>
> >>> I guess we can reuse the same infrastrcture backed by the generic
> >>> registry
> >>> but provide more specialized interfaces on top of it. And we can
> >>> also
> >>> choose
> >>> to have separate instances of registries for specific domains.
> >>>
> >>> >
> >>> > --
> >>> > Jeremy
> >>> >
> >>> > On Aug 30, 2006, at 4:10 AM, ant elder wrote:
> >>> >
> >>> >> Having this attached to a JIRA is fine, thats preferred over
> >>> sending
> >>> >> attachments to the dev list.
> >>> >>
> >>> >> Thanks for all this, I've only just started looking but it
> >>> looks very
> >>> >> comprehensive, a lot more than I was expecting 8-). I've a
> >>> few questions
> >>> >> so
> >>> >> far. Firstly you didn't click the button granting license of
> >>> the code
> >>> to
> >>> >> the
> >>> >> ASF, was that an oversight? The readme talks about some test
> >>> examples
> >>> >> and
> >>> >> samples showing how to use the registry but the test folders
> >>> don't seem
> >>> >> to
> >>> >> be included in the zip? From the brief look it wasn't clear to
> >>> me if
> >>> the
> >>> >> registry will require EMF, hopefully it doesn't?
> >>> >>
> >>> >> Thanks,
> >>> >>
> >>> >> ...ant
> >>> >>
> >>> >> On 8/30/06, Yang ZHONG <le...@gmail.com> wrote:
> >>> >>>
> >>> >>> Neither tuscany-dev nor infra takes my email with attachment,
> >>> so I've
> >>> >>> attached file for review into
> >>> >>> http://issues.apache.org/jira/browse/TUSCANY-677
> >>> >>>
> >>> >>> Sorry for the inconvenience and thanks for any comment.
> >>> >>>
> >>> >>> On 8/30/06, Mail Delivery Subsystem <mailer-
> >>> daemon@googlemail.com>
> >>> >>> wrote:
> >>> >>> >
> >>> >>> > This is an automatically generated Delivery Status
> >>> Notification
> >>> >>> >
> >>> >>> > Delivery to the following recipient failed permanently:
> >>> >>> >
> >>> >>> > infra@ws.apache.org
> >>> >>> >
> >>> >>> > Technical details of permanent failure:
> >>> >>> > PERM_FAILURE: SMTP Error (state 12): 552 Message rejected
> >>> as it
> >>> >>> is spam
> >>> >>> > (body)
> >>> >>> >
> >>> >>> > ----- Original message -----
> >>> >>> >
> >>> >>> > Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
> >>> >>> > Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
> >>> >>> > Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
> >>> >>> -0700
> >>> >>> (PDT)
> >>> >>> > Message-ID:
> >>> >>> <eae0faaf0608300306v6906b61ey95e006083d681761@mail.gmail.com
> >>> >>> >
> >>> >>> > Date: Wed, 30 Aug 2006 03:06:41 -0700
> >>> >>> > From: "Yang ZHONG" <le...@gmail.com>
> >>> >>> > To: tuscany-dev@ws.apache.org
> >>> >>> > Subject: Re: Auto discovering WSDL
> >>> >>> > Cc: infra@ws.apache.org
> >>> >>> > In-Reply-To:
> >>> >>> <eae0faaf0608241438t9b8cb72s8b92051ef3d0173a@mail.gmail.com
> >>> >>> >
> >>> >>> > MIME-Version: 1.0
> >>> >>> > Content-Type: multipart/mixed;
> >>> >>> > boundary="----=_Part_28704_31437365.1156932401933"
> >>> >>> > References: <
> >>> >>> > 244F5835C09CB641AE1D928BB2B0B9D8021CCD17@amereast-
> >>> >>> ems2.IONAGLOBAL.COM>
> >>> >>> >
> >>> >>> <ea...@mail.gmail.com>
> >>> >>> >
> >>> >>> <ea...@mail.gmail.com>
> >>> >>> >
> >>> >>> <71...@mail.gmail.com>
> >>> >>> >
> >>> >>> <ea...@mail.gmail.com>
> >>> >>> >
> >>> >>> > ------=_Part_28704_31437365.1156932401933
> >>> >>> > Content-Type: multipart/alternative;
> >>> >>> > boundary="----=_Part_28705_19724073.1156932401933"
> >>> >>> >
> >>> >>> > ------=_Part_28705_19724073.1156932401933
> >>> >>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >>> >>> > Content-Transfer-Encoding: 7bit
> >>> >>> > Content-Disposition: inline
> >>> >>> >
> >>> >>> > Could you please review the registry API and SPI?
> >>> >>> >
> >>> >>> > ----- Message truncated -----
> >>> >>> >
> >>> >>> >
> >>> >>>
> >>> >>>
> >>> >>> --
> >>> >>>
> >>> >>> Yang ZHONG
> >>> >>>
> >>> >>>
> >>> >
> >>> >
> >>> >
> >>> --------------------------------------------------------------------
> >>> -
> >>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>> >
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Yang ZHONG
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Jeremy Boynes <jb...@apache.org>.
I don't think we need "Provider" at all.
--
Jeremy
On Aug 30, 2006, at 9:59 AM, Jim Marino wrote:
> I had one additional comment: is there a reason we have to use the
> ".INSTANCE" approach to locating the default Provider?
>
> Jim
>
> On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
>
>> Raymond guessed right that it's an API/SPI review, so no impl/
>> tests attached
>> yet although I have some impl already.
>>
>> Ant guessed right too that I forgot to grant license, I must be
>> not thinking
>> straight working late :-)
>> I don't see any link to post-grant, I'll remember to do that for
>> following
>> attachments. Thank Ant.
>>
>> There's "neither* EMF *nor* Eclipse dependency. impl/EMF and impl/
>> Eclipse
>> are just subproject targeting certain usage.
>> Please take a look at ReadMe.txt for more details, it also have
>> info to find
>> Class Diagram and others.
>>
>> I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
>> preferred.
>> Actually, generalization and extensibility is exactly the selling
>> point of
>> this generic registry.
>> Tailoring can be done based on the framework/infrastructure/
>> fundation (as
>> Raymond commented).
>> There're at least two ways to provide strong interfaces over this
>> registry.
>> 2-1. Delegating
>> new StrongInterface()
>> {
>> public MySymbol getMySymbol (QName qName)
>> {
>> return mySymbolSpace.resolve( qName);
>> }
>> }
>> 2-2. Extending
>> class StrongInterfaceImpl extends SymbolSpaceImpl implement
>> StrongInterface
>>
>> Thank everyone for all comments.
>>
>> On 8/30/06, Raymond Feng <en...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> Please see my comments in line.
>>>
>>> Thanks,
>>> Raymond
>>>
>>> ----- Original Message -----
>>> From: "Jeremy Boynes" <jb...@apache.org>
>>> To: <tu...@ws.apache.org>
>>> Sent: Wednesday, August 30, 2006 8:19 AM
>>> Subject: Registry proposal, was: Delivery Status Notification
>>> (Failure)
>>>
>>>
>>> >I might be missing something as well but I didn't see any code
>>> under impl
>>> >at all
>>>
>>> I guess it's for the API/SPI review first.
>>>
>>> >
>>> > I'm also with Ant in thinking we should not have a dependency
>>> on EMF.
>>> >
>>>
>>> From the javadoc, I don't see the EMF dependencies.
>>>
>>> > I'd also add that I found it difficult to grok the
>>> relationships between
>>> > all the interfaces and inner-interfaces and how the behaviour
>>> would
>>> > integrate with Map semantics - for example, how does this
>>> differ from
>>> > just using strongly-typed Maps?
>>>
>>> I agree. If the interface is designed for public API/SPI, it
>>> should be
>>> first-class interface instead of being inner.
>>>
>>> I'm also seeing a lot of naming conflicts among API and SPI
>>> interfaces/classes/parameterized types. This seems to be very
>>> problematic
>>> to
>>> me. When we run out of names, it means to me we don't model it
>>> correctly.
>>>
>>> A class diagram would be of great help for us.
>>>
>>> >
>>> > I'm also not convinced that throwing everything (all types of
>>> stuff) into
>>> > one central registry model is a good way to go. I can see a
>>> lot of
>>> > benefit in having more specialized interfaces tailored for
>>> each type of
>>> > stuff.
>>>
>>> I guess we can reuse the same infrastrcture backed by the generic
>>> registry
>>> but provide more specialized interfaces on top of it. And we can
>>> also
>>> choose
>>> to have separate instances of registries for specific domains.
>>>
>>> >
>>> > --
>>> > Jeremy
>>> >
>>> > On Aug 30, 2006, at 4:10 AM, ant elder wrote:
>>> >
>>> >> Having this attached to a JIRA is fine, thats preferred over
>>> sending
>>> >> attachments to the dev list.
>>> >>
>>> >> Thanks for all this, I've only just started looking but it
>>> looks very
>>> >> comprehensive, a lot more than I was expecting 8-). I've a
>>> few questions
>>> >> so
>>> >> far. Firstly you didn't click the button granting license of
>>> the code
>>> to
>>> >> the
>>> >> ASF, was that an oversight? The readme talks about some test
>>> examples
>>> >> and
>>> >> samples showing how to use the registry but the test folders
>>> don't seem
>>> >> to
>>> >> be included in the zip? From the brief look it wasn't clear to
>>> me if
>>> the
>>> >> registry will require EMF, hopefully it doesn't?
>>> >>
>>> >> Thanks,
>>> >>
>>> >> ...ant
>>> >>
>>> >> On 8/30/06, Yang ZHONG <le...@gmail.com> wrote:
>>> >>>
>>> >>> Neither tuscany-dev nor infra takes my email with attachment,
>>> so I've
>>> >>> attached file for review into
>>> >>> http://issues.apache.org/jira/browse/TUSCANY-677
>>> >>>
>>> >>> Sorry for the inconvenience and thanks for any comment.
>>> >>>
>>> >>> On 8/30/06, Mail Delivery Subsystem <mailer-
>>> daemon@googlemail.com>
>>> >>> wrote:
>>> >>> >
>>> >>> > This is an automatically generated Delivery Status
>>> Notification
>>> >>> >
>>> >>> > Delivery to the following recipient failed permanently:
>>> >>> >
>>> >>> > infra@ws.apache.org
>>> >>> >
>>> >>> > Technical details of permanent failure:
>>> >>> > PERM_FAILURE: SMTP Error (state 12): 552 Message rejected
>>> as it
>>> >>> is spam
>>> >>> > (body)
>>> >>> >
>>> >>> > ----- Original message -----
>>> >>> >
>>> >>> > Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
>>> >>> > Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
>>> >>> > Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
>>> >>> -0700
>>> >>> (PDT)
>>> >>> > Message-ID:
>>> >>> <eae0faaf0608300306v6906b61ey95e006083d681761@mail.gmail.com
>>> >>> >
>>> >>> > Date: Wed, 30 Aug 2006 03:06:41 -0700
>>> >>> > From: "Yang ZHONG" <le...@gmail.com>
>>> >>> > To: tuscany-dev@ws.apache.org
>>> >>> > Subject: Re: Auto discovering WSDL
>>> >>> > Cc: infra@ws.apache.org
>>> >>> > In-Reply-To:
>>> >>> <eae0faaf0608241438t9b8cb72s8b92051ef3d0173a@mail.gmail.com
>>> >>> >
>>> >>> > MIME-Version: 1.0
>>> >>> > Content-Type: multipart/mixed;
>>> >>> > boundary="----=_Part_28704_31437365.1156932401933"
>>> >>> > References: <
>>> >>> > 244F5835C09CB641AE1D928BB2B0B9D8021CCD17@amereast-
>>> >>> ems2.IONAGLOBAL.COM>
>>> >>> >
>>> >>> <ea...@mail.gmail.com>
>>> >>> >
>>> >>> <ea...@mail.gmail.com>
>>> >>> >
>>> >>> <71...@mail.gmail.com>
>>> >>> >
>>> >>> <ea...@mail.gmail.com>
>>> >>> >
>>> >>> > ------=_Part_28704_31437365.1156932401933
>>> >>> > Content-Type: multipart/alternative;
>>> >>> > boundary="----=_Part_28705_19724073.1156932401933"
>>> >>> >
>>> >>> > ------=_Part_28705_19724073.1156932401933
>>> >>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>> >>> > Content-Transfer-Encoding: 7bit
>>> >>> > Content-Disposition: inline
>>> >>> >
>>> >>> > Could you please review the registry API and SPI?
>>> >>> >
>>> >>> > ----- Message truncated -----
>>> >>> >
>>> >>> >
>>> >>>
>>> >>>
>>> >>> --
>>> >>>
>>> >>> Yang ZHONG
>>> >>>
>>> >>>
>>> >
>>> >
>>> >
>>> --------------------------------------------------------------------
>>> -
>>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>> >
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>>
>> --
>>
>> Yang ZHONG
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Jim Marino <jm...@myromatours.com>.
I had one additional comment: is there a reason we have to use the
".INSTANCE" approach to locating the default Provider?
Jim
On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
> Raymond guessed right that it's an API/SPI review, so no impl/tests
> attached
> yet although I have some impl already.
>
> Ant guessed right too that I forgot to grant license, I must be not
> thinking
> straight working late :-)
> I don't see any link to post-grant, I'll remember to do that for
> following
> attachments. Thank Ant.
>
> There's "neither* EMF *nor* Eclipse dependency. impl/EMF and impl/
> Eclipse
> are just subproject targeting certain usage.
> Please take a look at ReadMe.txt for more details, it also have
> info to find
> Class Diagram and others.
>
> I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
> preferred.
> Actually, generalization and extensibility is exactly the selling
> point of
> this generic registry.
> Tailoring can be done based on the framework/infrastructure/
> fundation (as
> Raymond commented).
> There're at least two ways to provide strong interfaces over this
> registry.
> 2-1. Delegating
> new StrongInterface()
> {
> public MySymbol getMySymbol (QName qName)
> {
> return mySymbolSpace.resolve( qName);
> }
> }
> 2-2. Extending
> class StrongInterfaceImpl extends SymbolSpaceImpl implement
> StrongInterface
>
> Thank everyone for all comments.
>
> On 8/30/06, Raymond Feng <en...@gmail.com> wrote:
>>
>> Hi,
>>
>> Please see my comments in line.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: "Jeremy Boynes" <jb...@apache.org>
>> To: <tu...@ws.apache.org>
>> Sent: Wednesday, August 30, 2006 8:19 AM
>> Subject: Registry proposal, was: Delivery Status Notification
>> (Failure)
>>
>>
>> >I might be missing something as well but I didn't see any code
>> under impl
>> >at all
>>
>> I guess it's for the API/SPI review first.
>>
>> >
>> > I'm also with Ant in thinking we should not have a dependency on
>> EMF.
>> >
>>
>> From the javadoc, I don't see the EMF dependencies.
>>
>> > I'd also add that I found it difficult to grok the
>> relationships between
>> > all the interfaces and inner-interfaces and how the behaviour
>> would
>> > integrate with Map semantics - for example, how does this
>> differ from
>> > just using strongly-typed Maps?
>>
>> I agree. If the interface is designed for public API/SPI, it
>> should be
>> first-class interface instead of being inner.
>>
>> I'm also seeing a lot of naming conflicts among API and SPI
>> interfaces/classes/parameterized types. This seems to be very
>> problematic
>> to
>> me. When we run out of names, it means to me we don't model it
>> correctly.
>>
>> A class diagram would be of great help for us.
>>
>> >
>> > I'm also not convinced that throwing everything (all types of
>> stuff) into
>> > one central registry model is a good way to go. I can see a lot of
>> > benefit in having more specialized interfaces tailored for each
>> type of
>> > stuff.
>>
>> I guess we can reuse the same infrastrcture backed by the generic
>> registry
>> but provide more specialized interfaces on top of it. And we can also
>> choose
>> to have separate instances of registries for specific domains.
>>
>> >
>> > --
>> > Jeremy
>> >
>> > On Aug 30, 2006, at 4:10 AM, ant elder wrote:
>> >
>> >> Having this attached to a JIRA is fine, thats preferred over
>> sending
>> >> attachments to the dev list.
>> >>
>> >> Thanks for all this, I've only just started looking but it
>> looks very
>> >> comprehensive, a lot more than I was expecting 8-). I've a
>> few questions
>> >> so
>> >> far. Firstly you didn't click the button granting license of
>> the code
>> to
>> >> the
>> >> ASF, was that an oversight? The readme talks about some test
>> examples
>> >> and
>> >> samples showing how to use the registry but the test folders
>> don't seem
>> >> to
>> >> be included in the zip? From the brief look it wasn't clear to
>> me if
>> the
>> >> registry will require EMF, hopefully it doesn't?
>> >>
>> >> Thanks,
>> >>
>> >> ...ant
>> >>
>> >> On 8/30/06, Yang ZHONG <le...@gmail.com> wrote:
>> >>>
>> >>> Neither tuscany-dev nor infra takes my email with attachment,
>> so I've
>> >>> attached file for review into
>> >>> http://issues.apache.org/jira/browse/TUSCANY-677
>> >>>
>> >>> Sorry for the inconvenience and thanks for any comment.
>> >>>
>> >>> On 8/30/06, Mail Delivery Subsystem <mailer-
>> daemon@googlemail.com>
>> >>> wrote:
>> >>> >
>> >>> > This is an automatically generated Delivery Status Notification
>> >>> >
>> >>> > Delivery to the following recipient failed permanently:
>> >>> >
>> >>> > infra@ws.apache.org
>> >>> >
>> >>> > Technical details of permanent failure:
>> >>> > PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it
>> >>> is spam
>> >>> > (body)
>> >>> >
>> >>> > ----- Original message -----
>> >>> >
>> >>> > Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
>> >>> > Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
>> >>> > Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
>> >>> -0700
>> >>> (PDT)
>> >>> > Message-ID:
>> >>> <eae0faaf0608300306v6906b61ey95e006083d681761@mail.gmail.com
>> >>> >
>> >>> > Date: Wed, 30 Aug 2006 03:06:41 -0700
>> >>> > From: "Yang ZHONG" <le...@gmail.com>
>> >>> > To: tuscany-dev@ws.apache.org
>> >>> > Subject: Re: Auto discovering WSDL
>> >>> > Cc: infra@ws.apache.org
>> >>> > In-Reply-To:
>> >>> <eae0faaf0608241438t9b8cb72s8b92051ef3d0173a@mail.gmail.com
>> >>> >
>> >>> > MIME-Version: 1.0
>> >>> > Content-Type: multipart/mixed;
>> >>> > boundary="----=_Part_28704_31437365.1156932401933"
>> >>> > References: <
>> >>> > 244F5835C09CB641AE1D928BB2B0B9D8021CCD17@amereast-
>> >>> ems2.IONAGLOBAL.COM>
>> >>> >
>> >>> <ea...@mail.gmail.com>
>> >>> >
>> >>> <ea...@mail.gmail.com>
>> >>> >
>> >>> <71...@mail.gmail.com>
>> >>> >
>> >>> <ea...@mail.gmail.com>
>> >>> >
>> >>> > ------=_Part_28704_31437365.1156932401933
>> >>> > Content-Type: multipart/alternative;
>> >>> > boundary="----=_Part_28705_19724073.1156932401933"
>> >>> >
>> >>> > ------=_Part_28705_19724073.1156932401933
>> >>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> >>> > Content-Transfer-Encoding: 7bit
>> >>> > Content-Disposition: inline
>> >>> >
>> >>> > Could you please review the registry API and SPI?
>> >>> >
>> >>> > ----- Message truncated -----
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> Yang ZHONG
>> >>>
>> >>>
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> --
>
> Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Yang ZHONG <le...@gmail.com>.
Raymond guessed right that it's an API/SPI review, so no impl/tests attached
yet although I have some impl already.
Ant guessed right too that I forgot to grant license, I must be not thinking
straight working late :-)
I don't see any link to post-grant, I'll remember to do that for following
attachments. Thank Ant.
There's "neither* EMF *nor* Eclipse dependency. impl/EMF and impl/Eclipse
are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have info to find
Class Diagram and others.
I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
preferred.
Actually, generalization and extensibility is exactly the selling point of
this generic registry.
Tailoring can be done based on the framework/infrastructure/fundation (as
Raymond commented).
There're at least two ways to provide strong interfaces over this registry.
2-1. Delegating
new StrongInterface()
{
public MySymbol getMySymbol (QName qName)
{
return mySymbolSpace.resolve( qName);
}
}
2-2. Extending
class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface
Thank everyone for all comments.
On 8/30/06, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> Please see my comments in line.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Jeremy Boynes" <jb...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Wednesday, August 30, 2006 8:19 AM
> Subject: Registry proposal, was: Delivery Status Notification (Failure)
>
>
> >I might be missing something as well but I didn't see any code
> under impl
> >at all
>
> I guess it's for the API/SPI review first.
>
> >
> > I'm also with Ant in thinking we should not have a dependency on EMF.
> >
>
> From the javadoc, I don't see the EMF dependencies.
>
> > I'd also add that I found it difficult to grok the
> relationships between
> > all the interfaces and inner-interfaces and how the behaviour would
> > integrate with Map semantics - for example, how does this differ from
> > just using strongly-typed Maps?
>
> I agree. If the interface is designed for public API/SPI, it should be
> first-class interface instead of being inner.
>
> I'm also seeing a lot of naming conflicts among API and SPI
> interfaces/classes/parameterized types. This seems to be very problematic
> to
> me. When we run out of names, it means to me we don't model it correctly.
>
> A class diagram would be of great help for us.
>
> >
> > I'm also not convinced that throwing everything (all types of
> stuff) into
> > one central registry model is a good way to go. I can see a lot of
> > benefit in having more specialized interfaces tailored for each type of
> > stuff.
>
> I guess we can reuse the same infrastrcture backed by the generic registry
> but provide more specialized interfaces on top of it. And we can also
> choose
> to have separate instances of registries for specific domains.
>
> >
> > --
> > Jeremy
> >
> > On Aug 30, 2006, at 4:10 AM, ant elder wrote:
> >
> >> Having this attached to a JIRA is fine, thats preferred over sending
> >> attachments to the dev list.
> >>
> >> Thanks for all this, I've only just started looking but it looks very
> >> comprehensive, a lot more than I was expecting 8-). I've a
> few questions
> >> so
> >> far. Firstly you didn't click the button granting license of the code
> to
> >> the
> >> ASF, was that an oversight? The readme talks about some test examples
> >> and
> >> samples showing how to use the registry but the test folders
> don't seem
> >> to
> >> be included in the zip? From the brief look it wasn't clear to me if
> the
> >> registry will require EMF, hopefully it doesn't?
> >>
> >> Thanks,
> >>
> >> ...ant
> >>
> >> On 8/30/06, Yang ZHONG <le...@gmail.com> wrote:
> >>>
> >>> Neither tuscany-dev nor infra takes my email with attachment, so I've
> >>> attached file for review into
> >>> http://issues.apache.org/jira/browse/TUSCANY-677
> >>>
> >>> Sorry for the inconvenience and thanks for any comment.
> >>>
> >>> On 8/30/06, Mail Delivery Subsystem <ma...@googlemail.com>
> >>> wrote:
> >>> >
> >>> > This is an automatically generated Delivery Status Notification
> >>> >
> >>> > Delivery to the following recipient failed permanently:
> >>> >
> >>> > infra@ws.apache.org
> >>> >
> >>> > Technical details of permanent failure:
> >>> > PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it
> >>> is spam
> >>> > (body)
> >>> >
> >>> > ----- Original message -----
> >>> >
> >>> > Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
> >>> > Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
> >>> > Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
> >>> -0700
> >>> (PDT)
> >>> > Message-ID:
> >>> <eae0faaf0608300306v6906b61ey95e006083d681761@mail.gmail.com
> >>> >
> >>> > Date: Wed, 30 Aug 2006 03:06:41 -0700
> >>> > From: "Yang ZHONG" <le...@gmail.com>
> >>> > To: tuscany-dev@ws.apache.org
> >>> > Subject: Re: Auto discovering WSDL
> >>> > Cc: infra@ws.apache.org
> >>> > In-Reply-To:
> >>> <eae0faaf0608241438t9b8cb72s8b92051ef3d0173a@mail.gmail.com
> >>> >
> >>> > MIME-Version: 1.0
> >>> > Content-Type: multipart/mixed;
> >>> > boundary="----=_Part_28704_31437365.1156932401933"
> >>> > References: <
> >>> > 244F5835C09CB641AE1D928BB2B0B9D8021CCD17@amereast-
> >>> ems2.IONAGLOBAL.COM>
> >>> >
> >>> <ea...@mail.gmail.com>
> >>> >
> >>> <ea...@mail.gmail.com>
> >>> >
> >>> <71...@mail.gmail.com>
> >>> >
> >>> <ea...@mail.gmail.com>
> >>> >
> >>> > ------=_Part_28704_31437365.1156932401933
> >>> > Content-Type: multipart/alternative;
> >>> > boundary="----=_Part_28705_19724073.1156932401933"
> >>> >
> >>> > ------=_Part_28705_19724073.1156932401933
> >>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >>> > Content-Transfer-Encoding: 7bit
> >>> > Content-Disposition: inline
> >>> >
> >>> > Could you please review the registry API and SPI?
> >>> >
> >>> > ----- Message truncated -----
> >>> >
> >>> >
> >>>
> >>>
> >>> --
> >>>
> >>> Yang ZHONG
> >>>
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Please see my comments in line.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification (Failure)
>I might be missing something as well but I didn't see any code under impl
>at all
I guess it's for the API/SPI review first.
>
> I'm also with Ant in thinking we should not have a dependency on EMF.
>
>From the javadoc, I don't see the EMF dependencies.
> I'd also add that I found it difficult to grok the relationships between
> all the interfaces and inner-interfaces and how the behaviour would
> integrate with Map semantics - for example, how does this differ from
> just using strongly-typed Maps?
I agree. If the interface is designed for public API/SPI, it should be
first-class interface instead of being inner.
I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very problematic to
me. When we run out of names, it means to me we don't model it correctly.
A class diagram would be of great help for us.
>
> I'm also not convinced that throwing everything (all types of stuff) into
> one central registry model is a good way to go. I can see a lot of
> benefit in having more specialized interfaces tailored for each type of
> stuff.
I guess we can reuse the same infrastrcture backed by the generic registry
but provide more specialized interfaces on top of it. And we can also choose
to have separate instances of registries for specific domains.
>
> --
> Jeremy
>
> On Aug 30, 2006, at 4:10 AM, ant elder wrote:
>
>> Having this attached to a JIRA is fine, thats preferred over sending
>> attachments to the dev list.
>>
>> Thanks for all this, I've only just started looking but it looks very
>> comprehensive, a lot more than I was expecting 8-). I've a few questions
>> so
>> far. Firstly you didn't click the button granting license of the code to
>> the
>> ASF, was that an oversight? The readme talks about some test examples
>> and
>> samples showing how to use the registry but the test folders don't seem
>> to
>> be included in the zip? From the brief look it wasn't clear to me if the
>> registry will require EMF, hopefully it doesn't?
>>
>> Thanks,
>>
>> ...ant
>>
>> On 8/30/06, Yang ZHONG <le...@gmail.com> wrote:
>>>
>>> Neither tuscany-dev nor infra takes my email with attachment, so I've
>>> attached file for review into
>>> http://issues.apache.org/jira/browse/TUSCANY-677
>>>
>>> Sorry for the inconvenience and thanks for any comment.
>>>
>>> On 8/30/06, Mail Delivery Subsystem <ma...@googlemail.com>
>>> wrote:
>>> >
>>> > This is an automatically generated Delivery Status Notification
>>> >
>>> > Delivery to the following recipient failed permanently:
>>> >
>>> > infra@ws.apache.org
>>> >
>>> > Technical details of permanent failure:
>>> > PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it
>>> is spam
>>> > (body)
>>> >
>>> > ----- Original message -----
>>> >
>>> > Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
>>> > Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
>>> > Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
>>> -0700
>>> (PDT)
>>> > Message-ID:
>>> <eae0faaf0608300306v6906b61ey95e006083d681761@mail.gmail.com
>>> >
>>> > Date: Wed, 30 Aug 2006 03:06:41 -0700
>>> > From: "Yang ZHONG" <le...@gmail.com>
>>> > To: tuscany-dev@ws.apache.org
>>> > Subject: Re: Auto discovering WSDL
>>> > Cc: infra@ws.apache.org
>>> > In-Reply-To:
>>> <eae0faaf0608241438t9b8cb72s8b92051ef3d0173a@mail.gmail.com
>>> >
>>> > MIME-Version: 1.0
>>> > Content-Type: multipart/mixed;
>>> > boundary="----=_Part_28704_31437365.1156932401933"
>>> > References: <
>>> > 244F5835C09CB641AE1D928BB2B0B9D8021CCD17@amereast-
>>> ems2.IONAGLOBAL.COM>
>>> >
>>> <ea...@mail.gmail.com>
>>> >
>>> <ea...@mail.gmail.com>
>>> >
>>> <71...@mail.gmail.com>
>>> >
>>> <ea...@mail.gmail.com>
>>> >
>>> > ------=_Part_28704_31437365.1156932401933
>>> > Content-Type: multipart/alternative;
>>> > boundary="----=_Part_28705_19724073.1156932401933"
>>> >
>>> > ------=_Part_28705_19724073.1156932401933
>>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>> > Content-Transfer-Encoding: 7bit
>>> > Content-Disposition: inline
>>> >
>>> > Could you please review the registry API and SPI?
>>> >
>>> > ----- Message truncated -----
>>> >
>>> >
>>>
>>>
>>> --
>>>
>>> Yang ZHONG
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Registry proposal, was: Delivery Status Notification (Failure)
Posted by Jeremy Boynes <jb...@apache.org>.
I might be missing something as well but I didn't see any code under
impl at all
I'm also with Ant in thinking we should not have a dependency on EMF.
I'd also add that I found it difficult to grok the relationships
between all the interfaces and inner-interfaces and how the behaviour
would integrate with Map semantics - for example, how does this
differ from just using strongly-typed Maps?
I'm also not convinced that throwing everything (all types of stuff)
into one central registry model is a good way to go. I can see a lot
of benefit in having more specialized interfaces tailored for each
type of stuff.
--
Jeremy
On Aug 30, 2006, at 4:10 AM, ant elder wrote:
> Having this attached to a JIRA is fine, thats preferred over sending
> attachments to the dev list.
>
> Thanks for all this, I've only just started looking but it looks very
> comprehensive, a lot more than I was expecting 8-). I've a few
> questions so
> far. Firstly you didn't click the button granting license of the
> code to the
> ASF, was that an oversight? The readme talks about some test
> examples and
> samples showing how to use the registry but the test folders don't
> seem to
> be included in the zip? From the brief look it wasn't clear to me
> if the
> registry will require EMF, hopefully it doesn't?
>
> Thanks,
>
> ...ant
>
> On 8/30/06, Yang ZHONG <le...@gmail.com> wrote:
>>
>> Neither tuscany-dev nor infra takes my email with attachment, so I've
>> attached file for review into
>> http://issues.apache.org/jira/browse/TUSCANY-677
>>
>> Sorry for the inconvenience and thanks for any comment.
>>
>> On 8/30/06, Mail Delivery Subsystem <ma...@googlemail.com>
>> wrote:
>> >
>> > This is an automatically generated Delivery Status Notification
>> >
>> > Delivery to the following recipient failed permanently:
>> >
>> > infra@ws.apache.org
>> >
>> > Technical details of permanent failure:
>> > PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it
>> is spam
>> > (body)
>> >
>> > ----- Original message -----
>> >
>> > Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
>> > Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
>> > Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
>> -0700
>> (PDT)
>> > Message-ID:
>> <eae0faaf0608300306v6906b61ey95e006083d681761@mail.gmail.com
>> >
>> > Date: Wed, 30 Aug 2006 03:06:41 -0700
>> > From: "Yang ZHONG" <le...@gmail.com>
>> > To: tuscany-dev@ws.apache.org
>> > Subject: Re: Auto discovering WSDL
>> > Cc: infra@ws.apache.org
>> > In-Reply-To:
>> <eae0faaf0608241438t9b8cb72s8b92051ef3d0173a@mail.gmail.com
>> >
>> > MIME-Version: 1.0
>> > Content-Type: multipart/mixed;
>> > boundary="----=_Part_28704_31437365.1156932401933"
>> > References: <
>> > 244F5835C09CB641AE1D928BB2B0B9D8021CCD17@amereast-
>> ems2.IONAGLOBAL.COM>
>> >
>> <ea...@mail.gmail.com>
>> >
>> <ea...@mail.gmail.com>
>> >
>> <71...@mail.gmail.com>
>> >
>> <ea...@mail.gmail.com>
>> >
>> > ------=_Part_28704_31437365.1156932401933
>> > Content-Type: multipart/alternative;
>> > boundary="----=_Part_28705_19724073.1156932401933"
>> >
>> > ------=_Part_28705_19724073.1156932401933
>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> > Content-Transfer-Encoding: 7bit
>> > Content-Disposition: inline
>> >
>> > Could you please review the registry API and SPI?
>> >
>> > ----- Message truncated -----
>> >
>> >
>>
>>
>> --
>>
>> Yang ZHONG
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Delivery Status Notification (Failure)
Posted by ant elder <an...@gmail.com>.
Having this attached to a JIRA is fine, thats preferred over sending
attachments to the dev list.
Thanks for all this, I've only just started looking but it looks very
comprehensive, a lot more than I was expecting 8-). I've a few questions so
far. Firstly you didn't click the button granting license of the code to the
ASF, was that an oversight? The readme talks about some test examples and
samples showing how to use the registry but the test folders don't seem to
be included in the zip? From the brief look it wasn't clear to me if the
registry will require EMF, hopefully it doesn't?
Thanks,
...ant
On 8/30/06, Yang ZHONG <le...@gmail.com> wrote:
>
> Neither tuscany-dev nor infra takes my email with attachment, so I've
> attached file for review into
> http://issues.apache.org/jira/browse/TUSCANY-677
>
> Sorry for the inconvenience and thanks for any comment.
>
> On 8/30/06, Mail Delivery Subsystem <ma...@googlemail.com> wrote:
> >
> > This is an automatically generated Delivery Status Notification
> >
> > Delivery to the following recipient failed permanently:
> >
> > infra@ws.apache.org
> >
> > Technical details of permanent failure:
> > PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it is spam
> > (body)
> >
> > ----- Original message -----
> >
> > Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
> > Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
> > Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41 -0700
> (PDT)
> > Message-ID: <eae0faaf0608300306v6906b61ey95e006083d681761@mail.gmail.com
> >
> > Date: Wed, 30 Aug 2006 03:06:41 -0700
> > From: "Yang ZHONG" <le...@gmail.com>
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: Auto discovering WSDL
> > Cc: infra@ws.apache.org
> > In-Reply-To: <eae0faaf0608241438t9b8cb72s8b92051ef3d0173a@mail.gmail.com
> >
> > MIME-Version: 1.0
> > Content-Type: multipart/mixed;
> > boundary="----=_Part_28704_31437365.1156932401933"
> > References: <
> > 244F5835C09CB641AE1D928BB2B0B9D8021CCD17@amereast-ems2.IONAGLOBAL.COM>
> > <ea...@mail.gmail.com>
> > <ea...@mail.gmail.com>
> > <71...@mail.gmail.com>
> > <ea...@mail.gmail.com>
> >
> > ------=_Part_28704_31437365.1156932401933
> > Content-Type: multipart/alternative;
> > boundary="----=_Part_28705_19724073.1156932401933"
> >
> > ------=_Part_28705_19724073.1156932401933
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline
> >
> > Could you please review the registry API and SPI?
> >
> > ----- Message truncated -----
> >
> >
>
>
> --
>
> Yang ZHONG
>
>