You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Matthew Peters <ma...@uk.ibm.com> on 2008/03/04 16:52:57 UTC
Re: What are my chances of being able to "inherit" behaviour from
implementation.java?
Bad form to reply to my own posting I know but I wanted to ask: can or
should I raise this as formal requirement in some manner? It seems to me
that I won't be the only one who wants an architected way to reuse the
functionality from <implementation.java> - anything that is like a
servlet, in being both a java class and something else at the same time,
might want to do so.
Matthew Peters
Matthew Peters/UK/IBM@IBMGB
29/02/2008 17:50
Please respond to
tuscany-dev@ws.apache.org
To
tuscany-dev@ws.apache.org
cc
Subject
Re: What are my chances of being able to "inherit" behaviour from
implementation.java?
Hi Jean-Sebastien, thanks for a fast response.
What I am most interested in is the introspection and the ability to drive
injection. Life cycle and invocation on the other hand are not a concernt
because servlets have a very defined lifecycle and ideally that should all
be looked after by the web container.
Here is an example:
The .composite file might look like this:
<component name="StoreServletServiceComponent">
<implementation.servlet class="store.StoreServlet"/>
<reference name="catalogService" target="CatalogServiceComponent"
/>
<property ... some special servlet-specific properties> ...
</property>
</component>
<component name="CatalogServiceComponent">
<implementation.java class="services.CatalogImpl"/>
</component>
And with the servlet containing a setter for the reference, so looking for
all the world like a java component in this respect
@Reference
public void setCatalogService(Catalog catalogService) {
this.catalogService = catalogService;
}
private Catalog catalogService;
Yet doing something special with some of the properties, presenting them
as servlet init parameters, or example. So, I'm interested in:
1, introspection for references and properties
2. driving injection for references
3. driving injecttion for some properties
4. not doing injection for some other properties but doing something
different for them
Matthew Peters
Jean-Sebastien Delfino <js...@apache.org>
29/02/2008 16:51
Please respond to
tuscany-dev@ws.apache.org
To
tuscany-dev@ws.apache.org
cc
Subject
Re: What are my chances of being able to "inherit" behaviour from
implementation.java?
Matthew Peters wrote:
> Suppose I wanted to create a new implementation that shared much of the
> behaviour of <implementation.java> and then added a bit. Suppose I
wanted
> to make <implementation.servlet> for example, to be an implementation
that
> did what <implement.java> does WRT understanding @Reference and
@Property
> and getters and setters, but did some extra - for example looked in the
> web.xml file for the servlet and added some extra properties. How could
I
> architect this to take advantage of all the code that already exists
> within the support for <implementation.java>?
>
> Matthew Peters
>
We may need to refactor some of that function to make it available to
others as a proper SPI. Could you describe the bits you'd want to reuse
in more details?
- some of the implementation model?
- introspection of a Java class and creation of the corresponding
componentType model?
- injection of properties and references?
- invocation? I guess it's different here as a servlet has a fixed
interface pattern?
- anything else?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: What are my chances of being able to "inherit" behaviour from
implementation.java?
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
implementation.spring has many of the same dependencies. Once you have
an implementation type that is based on Java classes in some way, then
you end up needing a lot of the same mechanics that is there in
implementation.java
Yours, Mike.
Rajini Sivaram wrote:
> implementation.osgi and implementation.spring reuse introspection code from
> implementation.java. Both of these can avoid dependencies on
> implementation.java if the introspection/injection code is refactored to
> provide a proper SPI.
>
>
>
> On 3/4/08, Matthew Peters <ma...@uk.ibm.com> wrote:
>> Bad form to reply to my own posting I know but I wanted to ask: can or
>> should I raise this as formal requirement in some manner? It seems to me
>> that I won't be the only one who wants an architected way to reuse the
>> functionality from <implementation.java> - anything that is like a
>> servlet, in being both a java class and something else at the same time,
>> might want to do so.
>>
>> Matthew Peters
>>
>>
>>
>>
>> Matthew Peters/UK/IBM@IBMGB
>> 29/02/2008 17:50
>> Please respond to
>> tuscany-dev@ws.apache.org
>>
>>
>> To
>> tuscany-dev@ws.apache.org
>> cc
>>
>> Subject
>> Re: What are my chances of being able to "inherit" behaviour from
>> implementation.java?
>>
>>
>>
>>
>>
>>
>> Hi Jean-Sebastien, thanks for a fast response.
>>
>> What I am most interested in is the introspection and the ability to drive
>>
>> injection. Life cycle and invocation on the other hand are not a concernt
>> because servlets have a very defined lifecycle and ideally that should all
>>
>> be looked after by the web container.
>>
>> Here is an example:
>>
>> The .composite file might look like this:
>> <component name="StoreServletServiceComponent">
>> <implementation.servlet class="store.StoreServlet"/>
>> <reference name="catalogService" target="CatalogServiceComponent"
>> />
>> <property ... some special servlet-specific properties> ...
>> </property>
>> </component>
>>
>> <component name="CatalogServiceComponent">
>> <implementation.java class="services.CatalogImpl"/>
>> </component>
>>
>> And with the servlet containing a setter for the reference, so looking for
>>
>> all the world like a java component in this respect
>> @Reference
>> public void setCatalogService(Catalog catalogService) {
>> this.catalogService = catalogService;
>> }
>> private Catalog catalogService;
>>
>> Yet doing something special with some of the properties, presenting them
>> as servlet init parameters, or example. So, I'm interested in:
>>
>> 1, introspection for references and properties
>> 2. driving injection for references
>> 3. driving injecttion for some properties
>> 4. not doing injection for some other properties but doing something
>> different for them
>>
>>
>> Matthew Peters
>>
>>
>>
>>
>> Jean-Sebastien Delfino <js...@apache.org>
>> 29/02/2008 16:51
>> Please respond to
>> tuscany-dev@ws.apache.org
>>
>>
>> To
>> tuscany-dev@ws.apache.org
>> cc
>>
>> Subject
>> Re: What are my chances of being able to "inherit" behaviour from
>> implementation.java?
>>
>>
>>
>>
>>
>>
>> Matthew Peters wrote:
>>> Suppose I wanted to create a new implementation that shared much of the
>>> behaviour of <implementation.java> and then added a bit. Suppose I
>> wanted
>>> to make <implementation.servlet> for example, to be an implementation
>> that
>>> did what <implement.java> does WRT understanding @Reference and
>> @Property
>>> and getters and setters, but did some extra - for example looked in the
>>> web.xml file for the servlet and added some extra properties. How could
>> I
>>> architect this to take advantage of all the code that already exists
>>> within the support for <implementation.java>?
>>>
>>> Matthew Peters
>>>
>> We may need to refactor some of that function to make it available to
>> others as a proper SPI. Could you describe the bits you'd want to reuse
>> in more details?
>>
>> - some of the implementation model?
>>
>> - introspection of a Java class and creation of the corresponding
>> componentType model?
>>
>> - injection of properties and references?
>>
>> - invocation? I guess it's different here as a servlet has a fixed
>> interface pattern?
>>
>> - anything else?
>>
>> --
>> Jean-Sebastien
>>
>> ---------------------------------------------------------------------
>> 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: What are my chances of being able to "inherit" behaviour from implementation.java?
Posted by Rajini Sivaram <ra...@googlemail.com>.
implementation.osgi and implementation.spring reuse introspection code from
implementation.java. Both of these can avoid dependencies on
implementation.java if the introspection/injection code is refactored to
provide a proper SPI.
On 3/4/08, Matthew Peters <ma...@uk.ibm.com> wrote:
>
> Bad form to reply to my own posting I know but I wanted to ask: can or
> should I raise this as formal requirement in some manner? It seems to me
> that I won't be the only one who wants an architected way to reuse the
> functionality from <implementation.java> - anything that is like a
> servlet, in being both a java class and something else at the same time,
> might want to do so.
>
> Matthew Peters
>
>
>
>
> Matthew Peters/UK/IBM@IBMGB
> 29/02/2008 17:50
> Please respond to
> tuscany-dev@ws.apache.org
>
>
> To
> tuscany-dev@ws.apache.org
> cc
>
> Subject
> Re: What are my chances of being able to "inherit" behaviour from
> implementation.java?
>
>
>
>
>
>
> Hi Jean-Sebastien, thanks for a fast response.
>
> What I am most interested in is the introspection and the ability to drive
>
> injection. Life cycle and invocation on the other hand are not a concernt
> because servlets have a very defined lifecycle and ideally that should all
>
> be looked after by the web container.
>
> Here is an example:
>
> The .composite file might look like this:
> <component name="StoreServletServiceComponent">
> <implementation.servlet class="store.StoreServlet"/>
> <reference name="catalogService" target="CatalogServiceComponent"
> />
> <property ... some special servlet-specific properties> ...
> </property>
> </component>
>
> <component name="CatalogServiceComponent">
> <implementation.java class="services.CatalogImpl"/>
> </component>
>
> And with the servlet containing a setter for the reference, so looking for
>
> all the world like a java component in this respect
> @Reference
> public void setCatalogService(Catalog catalogService) {
> this.catalogService = catalogService;
> }
> private Catalog catalogService;
>
> Yet doing something special with some of the properties, presenting them
> as servlet init parameters, or example. So, I'm interested in:
>
> 1, introspection for references and properties
> 2. driving injection for references
> 3. driving injecttion for some properties
> 4. not doing injection for some other properties but doing something
> different for them
>
>
> Matthew Peters
>
>
>
>
> Jean-Sebastien Delfino <js...@apache.org>
> 29/02/2008 16:51
> Please respond to
> tuscany-dev@ws.apache.org
>
>
> To
> tuscany-dev@ws.apache.org
> cc
>
> Subject
> Re: What are my chances of being able to "inherit" behaviour from
> implementation.java?
>
>
>
>
>
>
> Matthew Peters wrote:
> > Suppose I wanted to create a new implementation that shared much of the
> > behaviour of <implementation.java> and then added a bit. Suppose I
> wanted
> > to make <implementation.servlet> for example, to be an implementation
> that
> > did what <implement.java> does WRT understanding @Reference and
> @Property
> > and getters and setters, but did some extra - for example looked in the
> > web.xml file for the servlet and added some extra properties. How could
> I
> > architect this to take advantage of all the code that already exists
> > within the support for <implementation.java>?
> >
> > Matthew Peters
> >
>
> We may need to refactor some of that function to make it available to
> others as a proper SPI. Could you describe the bits you'd want to reuse
> in more details?
>
> - some of the implementation model?
>
> - introspection of a Java class and creation of the corresponding
> componentType model?
>
> - injection of properties and references?
>
> - invocation? I guess it's different here as a servlet has a fixed
> interface pattern?
>
> - anything else?
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
>
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
--
Thank you...
Regards,
Rajini