Salut
Byron Nevins wrote:
> 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?
What about extending the WebContainer? This is already a module...Take a
look at Jetty, Grizzly and Tomcat. How do we do that as easy as they do
with your proposal?
A+
-- Jeanfrancois
>
>
>
> 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
>>
>