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 - 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]
-- Luciano Resende http://people.apache.org/~lresende
