On 5/7/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
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.
Adding to the list of options we have so far:
Option 0: Do nothing for this release
- as its not clear yet what the best way to do this is we don't mention or
provide samples for webapps in the 0.90 release. It might be better to not
mention webapss than to document a way to do them for this release which we
then immediately change for the following release
For JSPs it would be really nice if we could find a way to have the
SCADomain instance be a JSP implicit object so that for SCA webapp's there's
a scaDomain variable predefined in the JSP environment and the you don't
need anything like the useBean tag or application.getAttribute in the JSP
code.
It seems like there should be a consistent way for everything in a webapp to
get at the SCADomain - so multiple JSPs and servlets etc - and that whatever
is done to create the SCADomain is only defined once, eg, shouldn't need to
have:
if (domain == null) {
domain = SCADomain.newInstance("http://calc";, ".", "Calculator.composite
");
}
in multiple places.
It doesn't seem right to me to not support services in a webapp, if we can't
support services them maybe we just shouldn't support webapps at all.
What about scope? We probably need to support things like request and
session scope SCA components but the only way I can think of to do that is
to have a Tuscany servlet Filter that sets up the scope, and that Filter
needs to get defined somehow.
The only way I can think of of doing all those points in a standard webapp
is by defining a Tuscany specific Listener, Filter and Servlet in the
web.xml. If we took this approach one thing we could do is to support the
sca-contribution.xml file instead of using <context-param>'s.
Another approach would be to have a Tuscany specific customized Tomact
configuration so that defining the Tuscany specific web.xml things isn't
required and they get defined automatically during the webapp startup,
perhaps by noticing there's a META-INF/sca-contribution.xml file in the
webapp. This isn't to hard to do and is similar to the Tomcat 'deep
integration' we had in the M1 release. This seems quite a nice approach to
me but it does mean that Tuscany SCA webapps wont work in other webapp
runtimes without being modified to add in the web.xml config.
For this release I think I favour either option 0 or option 3 maybe modified
to support sca-contribution.xml instead of <context-param>.
...ant
