ant elder wrote:
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
The SCA assembly spec allows an implementation to define pre-configured
services with bindings. Here are a few examples:
- A composite implementation declares services and configures them with
bindings. All components implemented by that composite implementation
automatically get the services declared in the composite and their
default configuration.
- Any implementation can be pre-configured using a <componentType>, as
follows:
<componentType>
<service name="Hello">
<binding.ws/>
</service>
</componentType>
A more complete description of componentType can be found in section
1.4.1 of the assembly spec.
- In general the description of the implementation and the default
configuration of its services and references is determined by inspecting
the implementation artifact itself, for example:
- a composite implementation as mentioned above
- a Java implementation; support for bindings did not make it to the
1.0 spec, but support for interaction policies, which play in the same
space is in the 1.0 spec and described in section 2.6.1 of the SCA Java
API and Annotations spec
- a PHP implementation, as described in
http://www.osoa.org/display/PHP/PHP+and+SCA+White+Paper, using a
@binding.ws annotation in the implementation script.
So the new Resource implementation discussed here will just repeat that
pattern.
In revision r548609 I have committed an initial implementation of a
"resource" implementation and "resource" binding. The resource
implementation provides access to a resource directory, the resource
binding binds it to a Web URI. They can be used as follows:
<component name="webcontent">
<implementation.resource location="content"/>
</component>
makes the "content" folder available at http://localhost:8080/webcontent.
<component name="ResourceServiceComponent">
<service name="Resource">
<binding.resource uri="http://localhost:8085/wwwcontent"/>
</service>
<implementation.resource location="content"/>
</component>
makes the "content" folder available at http://localhost:8085/wwwcontent
This is an initial implementation, more work is probably needed to try
it with resources in Jars and Wars, and try syntax and naming variations
for the <implementation> and <binding> element (binding.web,
binding.http, or binding.resource?), but it's functional enough to allow
web content to be served along JSON-RPC and WS services.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
