You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2009/04/14 16:26:12 UTC

[1.x][DISCUSS] Locating and EAR file with implmentation.jee

I'm just thinking about the implementation.jee archive attribute and
what it means in the context of Tuscany. I've just updated the JEE
page on the wiki [1] with some alternative scenarios. There is no
reason for the order in which they are presented. This was just the
order they came out in. It seems that the spec text covers these two
scenarios.

2 - EAR is artifact in same contribution

Spec : The archive attribute specifies a relative path to the Java EE
archive that serves as
implementation artifact

<component name="xyz">
<implementation.jee archive="../my.ear"/>
</component>

5 - EAR is a self contained contribution

Spec : If EAR is a contribution @archive attribute can be left
unspecified, and the archive defaults to
be the archive of the contribution itself.

<component name="xyz">
<implementation.jee/>
</component>

These are a good place to start of course but what happens when we are
integrating with a real container? It seems to me that it is at least
likely that the ear file that a composite component refers to could be
added to the container separately from the composite application that
references it. If nothing else I would imagine there would need to be
some container specific processing involved in locating the ear
information.  In which case we need to look at how the ear information
can be processed through the contribution processors without the ear
being part of the contribution itself. Either scenario 1 or 3 from
[1].

I know we don't have implementation.jee runtime working yet so I'd be
interested to discuss what the plan is for allowing ear files to be
located in container specific ways.

Regards

Simon

[1] http://cwiki.apache.org/confluence/pages/editpage.action?pageId=96929

Re: [1.x][DISCUSS] Locating and EAR file with implmentation.jee

Posted by Simon Laws <si...@googlemail.com>.
On Tue, Apr 14, 2009 at 3:26 PM, Simon Laws <si...@googlemail.com> wrote:
> I'm just thinking about the implementation.jee archive attribute and
> what it means in the context of Tuscany. I've just updated the JEE
> page on the wiki [1] with some alternative scenarios. There is no
> reason for the order in which they are presented. This was just the
> order they came out in. It seems that the spec text covers these two
> scenarios.
>
> 2 - EAR is artifact in same contribution
>
> Spec : The archive attribute specifies a relative path to the Java EE
> archive that serves as
> implementation artifact
>
> <component name="xyz">
> <implementation.jee archive="../my.ear"/>
> </component>
>
> 5 - EAR is a self contained contribution
>
> Spec : If EAR is a contribution @archive attribute can be left
> unspecified, and the archive defaults to
> be the archive of the contribution itself.
>
> <component name="xyz">
> <implementation.jee/>
> </component>
>
> These are a good place to start of course but what happens when we are
> integrating with a real container? It seems to me that it is at least
> likely that the ear file that a composite component refers to could be
> added to the container separately from the composite application that
> references it. If nothing else I would imagine there would need to be
> some container specific processing involved in locating the ear
> information.  In which case we need to look at how the ear information
> can be processed through the contribution processors without the ear
> being part of the contribution itself. Either scenario 1 or 3 from
> [1].
>
> I know we don't have implementation.jee runtime working yet so I'd be
> interested to discuss what the plan is for allowing ear files to be
> located in container specific ways.
>
> Regards
>
> Simon
>
> [1] http://cwiki.apache.org/confluence/pages/editpage.action?pageId=96929
>

I just noticed that I've been sitting with uncommitted wiki changes in
my browser which I've just saved. Hopefully that makes this mail make
some kind of sense now.

Simon