On 6/13/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
ant elder wrote:
> On 6/13/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> In multiple instances I've run into an annoying limitation of our
>> embedded Tomcat and Jetty support... We cannot serve Web content, HTML
>> pages, scripts etc. when we run Tomcat or Jetty embedded in a J2SE
>> program. This makes it more difficult than it should be to test SCA
>> applications that use our JSON-RPC binding in particular, as you need
to
>> package these applications in WARs, deploy them to a standalone Tomcat
>> or Jetty, use remote debugging to step through them etc... as opposed
to
>> simply running them from a J2SE program's main()...
>>
>> I'd like to leverage a small variation of our Crud/resource
>> implementation type sample to fix that, and simply use a component to
>> serve web content out of a directory inside an application.
>>
>> Here's how the helloworld-jsonrpc sample composite will look with that
>> component implementation (see the BEGIN/END new-stuff section):
>>
>> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
>> targetNamespace="http://sample";
>> xmlns:sample="http://sample";
>> name="helloworldjsonrpc">
>>
>> <component name="HelloWorldJSONServiceComponent">
>> <service name="HelloWorldService">
>> <interface.java
>> interface="helloworldjsonrpc.HelloWorldService"/>
>> <binding.jsonrpc/>
>> </service>
>> <implementation.java
>> class="helloworldjsonrpc.HelloWorldServiceImpl"/>
>> </component>
>>
>> <!-- BEGIN new stuff -->
>>
>> <component name="MyHelloWorldContent">
>> <implementation.webResource location="location of the HTML and
>> JS files inside the contribution"/>
>> </component>
>>
>> <!-- END new stuff -->
>>
>> </composite>
>>
>> With that simple change, we will be able to run directly from J2SE and
>> serve Web content out of the configured directory... so we won't have
to
>> always package the whole app in a WAR and deploy it to a standalone Web
>> container.
>>
>> Thoughts?
>>
>> If there's no objection, I'd like to start adding that support later
>> this week.
>
>
> Sounds cool, and it would be really good for apps to work with the
> standalone http hosts.
>
> But what exactly does implementation.webResource do? Doesn't there
> need to
> be some sort of binding on the MyHelloWorldContent component to expose
> it as
> an http resource?
>
> ...ant
>
Yes, a simplified HTTP binding, which just registers the default file
servlet, configured with the binding's uri and the location specified on
the webResource, with the servlet host.
Since it's going to be pretty limited I'm not planning to expose it as a
new module separate from the implementation module, unless other Tuscans
are interested in it and want to pick it up.
in general application developers won't even have to know about it.
The following declaration:
<component name="MyHelloWorldContent">
<implementation.webResource location="myfiles"/>
</component>
will turn into a component declaring a default service with that default
HTTP binding configured to map uri="myfiles" to a file servlet serving
files in folder "myfiles".
If people really really really wanted to tweak the binding they would
write something like that:
<component name="MyHelloWorldContent">
<service name="web">
<binding.http uri="http://localhost:1234/myuri"/>
</service>
<implementation.webResource location="myfiles"/>
</component>
but I'm thinking about not implementing that XML support initially, and
wait until people actually ask for it before over-engineering this.
Maybe I'll get used to it now you've explained it but it did seem a bit
confusing to me that a component/implementation could magically use a
different default binding. Not sure if this is better or worse or even
allowed, but could it be some contribution file reader component thats
invisible and you use an explicit <service> with an http binding to make the
files available? Eg:
<service name="MyHelloWorldContent"
promote="ContrabutionReader/myFilesDir">
<binding.http />
</service>
...ant
