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 :)
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.
- 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.
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]
