If the user develops a module and it is in the Classpath when their
embedded-GF app runs, then GlassFish should automagically extend and
"expose" the module. What am I missing here?
Jeanfrancois Arcand wrote:
> 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
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
--
Byron Nevins Work 408-276-4089, Home 650-359-1290, Cell 650-784-4123 - Sun Microsystems, Inc.