Luciano Resende wrote:
Comments inline
On 5/7/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Luciano Resende wrote:
> Recently we have been prototyping around what should be our web client
> application story, and I think our main goal should be simplicity,
using
> approaches that are familiar to any web application developer.
>
> I have posted on our wiki [1] the description of three options that we
> have
> tried on calculator-web on the past couple days. Basically, I think
> option 2
> and 3 gives very similar results, but the usage of the jsp:useBean tag
> make
> things simpler, and does not require to register and use a
> contextListner.
> If we all agree, I'd like to propose using option 2, and would like to
> update calculator-web (that i have locally working with option2) to
> use this
> approach.
>
> Thoughts ? Should we demonstrate multiple options ? Otherwise, is it
> ok if I
> make calculator-web using the proposed approach ?
>
> [1]
>
http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+SCA+Web+Application+Integration+Story
>
>
I would not recommend option 1 as it's going to start/stop our runtime
on each click on a JSP, which doesn't look good to me in a server
environment :)
+1, but that was the first prototype we tried, so I just wanted to list
and expose why not to use that :)
I don't have s strong opinion in favor of 2 or 3, but I have a few
comments:
- Option 2 seems simpler than option 3 as it doesn't require the
application developer to worry at all about web.xml.
- Option 3 has the advantage of moving the declaration of our Tuscany
specific plumbing class outside of the JSPs.
- In both the jsp:useBean tag and web.xml cases, I don't like at all
configuring the composites in that XML as it's basically introducing
another XML language for what our spec has already defined in
sca-contribution.xml. The domain URI and the contribution location can
be derived from the current Web app context so I would suggest to remove
these other configuration options as well, as a multiplicity of options
to do the same thing in a myriad of XML files is not helping application
developers IMO.
Regarding configuring the composites, I think you are bringing up the
same
issue I raised in this post, regarding the method/constructor
signatures of
SCADomain [1]
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg17465.html
I thought that the issue raised in [1] was different.
[1] is about the Java API allowing you to specify deployables as an
alternative to XML. I think that such a Java API is a useful
alternative, as it saves you from writing yet another XML file.
What's different here is that we're talking about a home grown XML
alternative to sca-contribution.xml. Another XML form to repeat what we
can write in sca-contribution.xml does not look so useful to me.
- Web.xml can be used to register a generic Tuscany servlet which will
be used to expose Web services and JSONRPC services out of the web app.
If we think that this is a popular scenario, option 3 will be slightly
better as it will group all our definitions in one place. However I'm
still not sure that webapps should be our preferred packaging mechanism
for SCA applications that expose services.
Yes, maybe something we should raise on the spec group ? As there
seems to
be some discussion around J2EE scenarios/packaging, etc at the moment ?
I'll think about it more today, and may post more thoughts later.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
