You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2007/05/17 04:43:50 UTC
A convention for deployable composites, was: Web Application integration
story
ant elder wrote:
> Ok, i re-read this last email again [1] and i guess i missed the
> "...if we
> could make it work consistently, with JARs as well as WARs" bit
> before. I'm
> not sure I agree with that, why should WARs be hamstrung with a less user
> friendly way of working just because jars can't work as easily? If we can
> have this really simple approach working in WARs why not support it,
> its not
> like jars and wars are interchangeable?
>
> ...ant
>
> [1]
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200705.mbox/%3c4649EDE5.9070308@apache.org%3e
>
>
A few more thoughts. I have 2 problems with this approach... but I think
your requirement is very valid and I have a proposal at the end of this
email :)
1. This approach doesn't work the same way in a JAR, a folder, a WAR, an
expanded Web app folder. I'm looking for consistency in the programming
model and any conventions we implement. We could probably get this
working with a JAR if SCADomain.newInstance() could take as a parameter
a class belonging to the SCA contribution which we could use to
determine its location, but that would be one more option and too many
options are just going to complicate the application developer's life IMO.
2. I find this approach a little too error prone and it may actually
complicate my life as an app developer in some cases. Here are a few fun
scenarios to illustrate that...
- I could start developing a contribution and place my deployable
composites at the root of the contribution, without an
sca-contribution.xml. Then at some point, let's imagine that I need an
sca-contribution.xml to import a WSDL or XSD for example, all of a
sudden I'm going to have to list all my composites in
sca-contribution.xml to get them deployed now (as the automatic
deployment behavior won't be available to me anymore). So something that
initially seemed simple, add an <import> of a namespace to a
contribution, will actually require more significant development work.
I'll have to open all composites, find their names and namespaces and
spend some time in my sca-contribution.xml to declare them.
- Another scenario, removing an sca-contribution.xml (because I don't
need any XML imports or exports anymore at some point for example) may
inadvertently expose all the .composites file at the root of my
contribution as deployables. So I would have to move them out of there.
- Another interesting one I think. SCA contributions can be used to
package implementation artifacts, .java, .scripts, and .composites for
example. Most of these contributions will not contribute any
deployables, and will not contain an sca-contribution.xml. Then I would
have to be really careful to not place any of these deployables at the
root of these contributions, to prevent them to be automatically added
to the SCA domain as deployables.
All of that doesn't sound too good to me, but I don't like to write XML
files either so, like you, I'd be happy to see a simple approach to just
place deployable .composite files in a well known location instead of
writing a page of angle brackets...
Now here's an idea, which I think could give you what you're looking for:
- Deployable .composite files could be placed in
META-INF/sca-deployables. We will consider all the files in that folder
as deployables.
- This folder could co-exist with a META-INF/sca-contribution.xml, and
it would be an extension of the <deployable> list in sca-contribution.xml.
- This would be supported in the same way in all contribution types,
JARs, WARs, folders, web app folders. We would just implement this
behavior once in the ContributionService.
I think this would give you what you're looking for (no XML, a
convention location for deployables). It makes clear that these are
deployables, doesn't generate more work, inconsistencies or surprises
when you add/remove an sca-contribution.xml file. It's also easy to
implement as it's very close to the previous code that we had in
ContributionService which used to add all composites as deployables.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: A convention for deployable composites, was: Web Application
integration story
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> ant elder wrote:
>> Ok, i re-read this last email again [1] and i guess i missed the
>> "...if we
>> could make it work consistently, with JARs as well as WARs" bit
>> before. I'm
>> not sure I agree with that, why should WARs be hamstrung with a less
>> user
>> friendly way of working just because jars can't work as easily? If we
>> can
>> have this really simple approach working in WARs why not support it,
>> its not
>> like jars and wars are interchangeable?
>>
>> ...ant
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200705.mbox/%3c4649EDE5.9070308@apache.org%3e
>>
>>
>
> A few more thoughts. I have 2 problems with this approach... but I
> think your requirement is very valid and I have a proposal at the end
> of this email :)
>
> 1. This approach doesn't work the same way in a JAR, a folder, a WAR,
> an expanded Web app folder. I'm looking for consistency in the
> programming model and any conventions we implement. We could probably
> get this working with a JAR if SCADomain.newInstance() could take as a
> parameter a class belonging to the SCA contribution which we could use
> to determine its location, but that would be one more option and too
> many options are just going to complicate the application developer's
> life IMO.
>
> 2. I find this approach a little too error prone and it may actually
> complicate my life as an app developer in some cases. Here are a few
> fun scenarios to illustrate that...
>
> - I could start developing a contribution and place my deployable
> composites at the root of the contribution, without an
> sca-contribution.xml. Then at some point, let's imagine that I need an
> sca-contribution.xml to import a WSDL or XSD for example, all of a
> sudden I'm going to have to list all my composites in
> sca-contribution.xml to get them deployed now (as the automatic
> deployment behavior won't be available to me anymore). So something
> that initially seemed simple, add an <import> of a namespace to a
> contribution, will actually require more significant development work.
> I'll have to open all composites, find their names and namespaces and
> spend some time in my sca-contribution.xml to declare them.
>
> - Another scenario, removing an sca-contribution.xml (because I don't
> need any XML imports or exports anymore at some point for example) may
> inadvertently expose all the .composites file at the root of my
> contribution as deployables. So I would have to move them out of there.
>
> - Another interesting one I think. SCA contributions can be used to
> package implementation artifacts, .java, .scripts, and .composites for
> example. Most of these contributions will not contribute any
> deployables, and will not contain an sca-contribution.xml. Then I
> would have to be really careful to not place any of these deployables
> at the root of these contributions, to prevent them to be
> automatically added to the SCA domain as deployables.
>
> All of that doesn't sound too good to me, but I don't like to write
> XML files either so, like you, I'd be happy to see a simple approach
> to just place deployable .composite files in a well known location
> instead of writing a page of angle brackets...
>
> Now here's an idea, which I think could give you what you're looking for:
>
> - Deployable .composite files could be placed in
> META-INF/sca-deployables. We will consider all the files in that
> folder as deployables.
>
> - This folder could co-exist with a META-INF/sca-contribution.xml, and
> it would be an extension of the <deployable> list in
> sca-contribution.xml.
>
> - This would be supported in the same way in all contribution types,
> JARs, WARs, folders, web app folders. We would just implement this
> behavior once in the ContributionService.
>
> I think this would give you what you're looking for (no XML, a
> convention location for deployables). It makes clear that these are
> deployables, doesn't generate more work, inconsistencies or surprises
> when you add/remove an sca-contribution.xml file. It's also easy to
> implement as it's very close to the previous code that we had in
> ContributionService which used to add all composites as deployables.
>
> Thoughts?
>
I added the logic to handle this in revision r538820. It's harmless, if
people don't like that convention we don't have to follow it, but if we
like it, it's now implemented.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: A convention for deployable composites, was: Web Application integration story
Posted by ant elder <an...@gmail.com>.
On 5/17/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > Ok, i re-read this last email again [1] and i guess i missed the
> > "...if we
> > could make it work consistently, with JARs as well as WARs" bit
> > before. I'm
> > not sure I agree with that, why should WARs be hamstrung with a less
> user
> > friendly way of working just because jars can't work as easily? If we
> can
> > have this really simple approach working in WARs why not support it,
> > its not
> > like jars and wars are interchangeable?
> >
> > ...ant
> >
> > [1]
> >
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200705.mbox/%3c4649EDE5.9070308@apache.org%3e
> >
> >
>
> A few more thoughts. I have 2 problems with this approach... but I think
> your requirement is very valid and I have a proposal at the end of this
> email :)
>
> 1. This approach doesn't work the same way in a JAR, a folder, a WAR, an
> expanded Web app folder. I'm looking for consistency in the programming
> model and any conventions we implement. We could probably get this
> working with a JAR if SCADomain.newInstance() could take as a parameter
> a class belonging to the SCA contribution which we could use to
> determine its location, but that would be one more option and too many
> options are just going to complicate the application developer's life IMO.
>
> 2. I find this approach a little too error prone and it may actually
> complicate my life as an app developer in some cases. Here are a few fun
> scenarios to illustrate that...
>
> - I could start developing a contribution and place my deployable
> composites at the root of the contribution, without an
> sca-contribution.xml. Then at some point, let's imagine that I need an
> sca-contribution.xml to import a WSDL or XSD for example, all of a
> sudden I'm going to have to list all my composites in
> sca-contribution.xml to get them deployed now (as the automatic
> deployment behavior won't be available to me anymore). So something that
> initially seemed simple, add an <import> of a namespace to a
> contribution, will actually require more significant development work.
> I'll have to open all composites, find their names and namespaces and
> spend some time in my sca-contribution.xml to declare them.
>
> - Another scenario, removing an sca-contribution.xml (because I don't
> need any XML imports or exports anymore at some point for example) may
> inadvertently expose all the .composites file at the root of my
> contribution as deployables. So I would have to move them out of there.
>
> - Another interesting one I think. SCA contributions can be used to
> package implementation artifacts, .java, .scripts, and .composites for
> example. Most of these contributions will not contribute any
> deployables, and will not contain an sca-contribution.xml. Then I would
> have to be really careful to not place any of these deployables at the
> root of these contributions, to prevent them to be automatically added
> to the SCA domain as deployables.
>
> All of that doesn't sound too good to me, but I don't like to write XML
> files either so, like you, I'd be happy to see a simple approach to just
> place deployable .composite files in a well known location instead of
> writing a page of angle brackets...
>
> Now here's an idea, which I think could give you what you're looking for:
>
> - Deployable .composite files could be placed in
> META-INF/sca-deployables. We will consider all the files in that folder
> as deployables.
>
> - This folder could co-exist with a META-INF/sca-contribution.xml, and
> it would be an extension of the <deployable> list in sca-contribution.xml.
>
> - This would be supported in the same way in all contribution types,
> JARs, WARs, folders, web app folders. We would just implement this
> behavior once in the ContributionService.
>
> I think this would give you what you're looking for (no XML, a
> convention location for deployables). It makes clear that these are
> deployables, doesn't generate more work, inconsistencies or surprises
> when you add/remove an sca-contribution.xml file. It's also easy to
> implement as it's very close to the previous code that we had in
> ContributionService which used to add all composites as deployables.
>
> Thoughts?
Sounds good to me.
...ant
Re: A convention for deployable composites, was: Web Application integration story
Posted by Venkata Krishnan <fo...@gmail.com>.
+1. This really puts some certainity into what actually gets deployed.
- Venkat
On 5/17/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > Ok, i re-read this last email again [1] and i guess i missed the
> > "...if we
> > could make it work consistently, with JARs as well as WARs" bit
> > before. I'm
> > not sure I agree with that, why should WARs be hamstrung with a less
> user
> > friendly way of working just because jars can't work as easily? If we
> can
> > have this really simple approach working in WARs why not support it,
> > its not
> > like jars and wars are interchangeable?
> >
> > ...ant
> >
> > [1]
> >
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200705.mbox/%3c4649EDE5.9070308@apache.org%3e
> >
> >
>
> A few more thoughts. I have 2 problems with this approach... but I think
> your requirement is very valid and I have a proposal at the end of this
> email :)
>
> 1. This approach doesn't work the same way in a JAR, a folder, a WAR, an
> expanded Web app folder. I'm looking for consistency in the programming
> model and any conventions we implement. We could probably get this
> working with a JAR if SCADomain.newInstance() could take as a parameter
> a class belonging to the SCA contribution which we could use to
> determine its location, but that would be one more option and too many
> options are just going to complicate the application developer's life IMO.
>
> 2. I find this approach a little too error prone and it may actually
> complicate my life as an app developer in some cases. Here are a few fun
> scenarios to illustrate that...
>
> - I could start developing a contribution and place my deployable
> composites at the root of the contribution, without an
> sca-contribution.xml. Then at some point, let's imagine that I need an
> sca-contribution.xml to import a WSDL or XSD for example, all of a
> sudden I'm going to have to list all my composites in
> sca-contribution.xml to get them deployed now (as the automatic
> deployment behavior won't be available to me anymore). So something that
> initially seemed simple, add an <import> of a namespace to a
> contribution, will actually require more significant development work.
> I'll have to open all composites, find their names and namespaces and
> spend some time in my sca-contribution.xml to declare them.
>
> - Another scenario, removing an sca-contribution.xml (because I don't
> need any XML imports or exports anymore at some point for example) may
> inadvertently expose all the .composites file at the root of my
> contribution as deployables. So I would have to move them out of there.
>
> - Another interesting one I think. SCA contributions can be used to
> package implementation artifacts, .java, .scripts, and .composites for
> example. Most of these contributions will not contribute any
> deployables, and will not contain an sca-contribution.xml. Then I would
> have to be really careful to not place any of these deployables at the
> root of these contributions, to prevent them to be automatically added
> to the SCA domain as deployables.
>
> All of that doesn't sound too good to me, but I don't like to write XML
> files either so, like you, I'd be happy to see a simple approach to just
> place deployable .composite files in a well known location instead of
> writing a page of angle brackets...
>
> Now here's an idea, which I think could give you what you're looking for:
>
> - Deployable .composite files could be placed in
> META-INF/sca-deployables. We will consider all the files in that folder
> as deployables.
>
> - This folder could co-exist with a META-INF/sca-contribution.xml, and
> it would be an extension of the <deployable> list in sca-contribution.xml.
>
> - This would be supported in the same way in all contribution types,
> JARs, WARs, folders, web app folders. We would just implement this
> behavior once in the ContributionService.
>
> I think this would give you what you're looking for (no XML, a
> convention location for deployables). It makes clear that these are
> deployables, doesn't generate more work, inconsistencies or surprises
> when you add/remove an sca-contribution.xml file. It's also easy to
> implement as it's very close to the previous code that we had in
> ContributionService which used to add all composites as deployables.
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>