Salut,
Kohsuke Kawaguchi wrote:
> Jeanfrancois Arcand wrote:
>> Salut,
>>
>> sorry I've missed the date, but I do think you are missing some
>> important features :-)
>>
>> A+
>>
>> -- Jeanfrancois
>>
>> -------- Original Message --------
>> Subject: Re: Request For Comments - Embeddable GlassFish Functional
>> Specifications
>> Date: Tue, 22 Jul 2008 22:26:28 -0400
>> From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
>> Reply-To: users_at_glassfish.dev.java.net
>> To: users_at_glassfish.dev.java.net
>> References:
>> <27196713.10521216415432809.JavaMail.tomcat_at_sdcst12.sjc.collab.net>
>>
>> Salut,
>>
>> probably late, but anyway :-)
>>
>> I looked at the one pager, but there is one thing we are missing. There
>> is two reason to use an Embed API:
>>
>> (1) Embed the Container into your application
>> (2) Embed and *extend* the Container into your application
>>
>> The current proposal only supports (1). If someone wants to add features
>> to GlassFish, there is no way to do such thing as nothing is exposed.
>
> All the internal/public APIs are 'exposed' in the embedded mode, in the
> sense that you can write code that links to those. So with the same
> amount of effort it takes to develop a module (that is, to figure out
> where to hook in and how), you can extend GFv3 from within your
> application.
>
> So I think it's really just a matter of the functional spec calling that
> out as an important feature, and hopefully we'll have a tutorial or two
> with associated blog entries to show how to do it.
Hum....at least for the WebContainer, I don't see how this can be
achieved easily. Of course we can use JMX and reach some object, but
just adding a Valve seems quite complex with the current approach. Just
looking at how Tomcat/Jetty supports extension, we should try to make it
as easy :-)
A+
-- Jeanfrancois
>
>
>
>
>> You should take a look at
>>
>> Grizzly Embed [1] (GrizzlyAdapter, AsyncFilter)
>> Jetty Embed [2] (Handler)
>> Tomcat Embed [3] (Adapter, Valves)
>>
>> They *all* support a mechanism to extend the default behavior. The
>> current proposal is missing that, and I do think we should think about
>> exposing either some of the WebContainer extension point (Valve),
>> Grizzly (Adapter, AsyncFilter, ProtocolFilter) or some GlassFish home
>> made.
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>> [1]
>> https://grizzly.dev.java.net/nonav/apidocs/com/sun/grizzly/http/embed/GrizzlyWebServer.html
>>
>> [2] http://docs.codehaus.org/display/JETTY/Embedding+Jetty
>> [3]
>> http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/startup/Embedded.html
>>
>>
>> glassfish_at_javadesktop.org wrote:
>>> Section 4.1.3
>>>
>>> 1. Can you explain how the ClassLoaders are setup (if any) when
>>> embedded GF starts? If we are going to use just the caller's
>>> ClassLoader please state that.
>>>
>>> [b]*** A quick answer is -- Yes we use the caller's ClassLoader[/b]
>>>
>>> 2. Are we going to support running JPA applications inside this
>>> embedded GF? Typically, JPA implementations (like TopLink) require
>>> special ClassLoaders to add Transformers to instrument classes.
>>>
>>> [b]This is one of many future complications that we will need to
>>> address. But, yes, we do plan to support JPA.[/b]
>>>
>>> 3. Can you list what services will be available in the embedded GF?
>>> (Like Security, Transaction etc.)
>>> [b]All Services that are in the web distribution -- for Prelude[/b]
>>>
>>> 4. If the Embedding (the caller's) VM already using a NamingManager,
>>> does the embedded GF should use that (instead of creating our
>>> NamingManager)? Please clarify.
>>>
>>> [b]Again this is another complication that will be addresses
>>> post-prelude[/b]
>>>
>>> Section 4.1.6
>>>
>>> The example that uses ScatteredWar seem to suggest that the deployed
>>> app need not follow the regular .war structure? Can you elaborate
>>> more about the layout (if any) of the apps that can be deployed?
>>>
>>> [b]It's pretty simple. You pass in: Name of App, web.xml location,
>>> resources location and classes location.[/b]
>>> Also, instead of the user having to create a ScatteredWar, can we not
>>> do glassfish.deploy(String appName, File... locations)?
>>> [b]No. ScatteredWar is doing more than just gathering file
>>> locations. It is needed...[/b]
>>>
>>> Can you explain what exactly is done during glassfish.stop()
>>>
>>> [b]All Startup services are released then all Init Services are
>>> released.[/b]
>>>
>>> Thanks,
>>> --Mahesh
>>> [Message sent by forum member 'bnevins' (bnevins)]
>>>
>>> http://forums.java.net/jive/thread.jspa?messageID=287740
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>
>