Salut,
apology for the delay....
Richard Jackson wrote:
> Man that was fast! I was just wondering if I could do it and here you
> go and implement it that fast wow....
>
> The one down fall I see is that you would have to make sure that the
> HTTP headers have been wrote to the channel before making the call.
> Need to figure out how to do that. (maybe just flush the output
> stream?)
Right, by invoking response.sendHeaders();
>
> Any ways I have allot of work to do before I get to that point. What
> I'm looking to do is a OSGi HttpService implementation using grizzly.
> For that all I really need is a ServletAdapter and the httpServer (I
> think at this point I would like to expose the commet stuff as well).
> So I'm still reading at this point as what you have will not quite
> work the way the spec has it. I'm thinking I will need to rewrite the
> ServletAdapter (modify it really) to do what I need for the OSGi
> HttpService.
If you can share your works, I would be happy to help :-)
The differences mostly have to do with the way you handle
> contexts and there is a very specific way you have to resolve URL's ->
> servlet/resource. (Oh this is something I'm more than willing
> contribute to grizzly it would be the light weight alternative to gfv3
> and jetty for those that don't need JSP's or war file deployments)
Great!
>
> For some of the things I have in mind for using this for having that
> interface will come in very handy. (WebDEV and large image content).
> But in all reality if I understand the underlying call that the method
> uses (at least on Linux that is) this will reduce memory usage
> (application memory usage) and let the OS manage doing the cache
> (which Linux will do BTW actually it will use most if not all unused
> memory for file system read cache)
Right.
>
> Any ways looks like I found the right project and should get to work
> on implementing it.
>
> Oh let me know if
> 1) Would would like to have an OSGi HTTPService implementation as part
> of Grizzly
+ 1 Yes this is really something I would like to see.
> 2) What I would need to do for you to be able to accept it (I assume I
> would need to sign a Sun contributor agreement)
Yes. If you can sign it and send it to ( charlie.hunt at sun dot com ):
https://glassfish.dev.java.net/public/GovernancePolicy.html
http://www.sun.com/software/opensource/sca.pdf
I will gives you access to the trunk/contribs svn workspace so you can
do you work there. Once we think this is realy, we will just move it to
the trunk and start releasing it officially.
>
> Either way I will let you know how it is going and also drop you a
> line if I run into issues.
>
Many thanks!
-- Jeanfrancois
> Thanks
> Richard
>
> On Thu, Nov 13, 2008 at 4:55 PM, Jeanfrancois Arcand
> <Jeanfrancois.Arcand_at_sun.com> wrote:
>> Salut,
>>
>> Jeanfrancois Arcand wrote:
>>> Salut,
>>>
>>> Richard Jackson wrote:
>>>> I'm just starting to look at grizzly and trying to decide if I want to
>>>> use it verses something else. So I've been looking at the api's and
>>>> javadocs and samples. One thing I don't see covered is how you are
>>>> actually serving static content. From browsing the javadoc it seems
>>>> you are using the traditional approach (read the file in then write it
>>>> out to the channel) as well as possibly caching the file data.
>>> Right. First request is serviced by reading the file, then the file is
>>> mapped using native memory and the reference cached. Next all requests got
>>> serviced from the cache. The class to look at are:
>>>
>>> StaticResourceAdapter
>>>
>>>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/StaticResourcesAdapter.html
>>> FileCache
>>>
>>>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/http/FileCache.html
>>>
>>> Why not
>>>> let the OS do that for you? Take a look at this article
>>>> http://www.ibm.com/developerworks/linux/library/j-zerocopy/index.html
>>> That's look promising.
>>>
>>>
>>>> I'm not sure if the approach described works on all platforms but the
>>>> question I have is can I get at the channel and do it myself when
>>>> using a GrizzlyWebServer?
>>> Yes you can probably do that by doing (this is ugly)
>>>
>>> ((SocketChannelOutputBuffer)response.getOutputBuffer()).getChannel();
>>>
>>>
>>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/Response.html#178
>>>
>>> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/http/SocketChannelOutputBuffer.html#123
>>>
>>> I've filled:
>>>
>>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=319
>> Fixed. That will be part of our next release (1.9.0) and available right now
>> using the SNAPSHOT/uploaded build from here:
>>
>> http://download.java.net/maven/2/com/sun/grizzly/
>>
>> Make sure you read the API documentation. In short, if you manipulate the
>> SocketChannel, you must make sure you either let Grizzly handle the http
>> headers, or handle it by yourself.
>>
>> https://grizzly.dev.java.net/nonav/apidocs/com/sun/grizzly/tcp/Response.html
>>
>> (uploading the new html now so refresh in a couple of min)
>>
>> Let me know how it goes.
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>> And will add a new API on the Request/Response object called getChannel so
>>> you can take advantages of it. I should have it later this week or Monday
>>> for sure.
>>>
>>> Thanks
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>
>>>> Thanks
>>>> Richard
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>