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 <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED]
29/02/2008 17:50
Please respond to
[email protected]
To
[email protected]
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 <[EMAIL PROTECTED]>
29/02/2008 16:51
Please respond to
[email protected]
To
[email protected]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
