Sorry for not being more involved - got blind sided by management and am
now just starting to crawl out of from under.
I agree, that EmbeddedInfo needs to be more complete. My original
impression when I started looking at Embedded Glassfish was that it
would allow me to completely define a configuration via the API - so I
would not need static configuration files.
Besides multiple listeners per server, I also need to configure SSL for
one of my listeners.
Right now, I hack it all by a combination of modified the text of a
template domain.xml file and the Embedded API that does exist.
joey
________________________________
From: Nazrul.Islam_at_Sun.COM [mailto:Nazrul.Islam_at_Sun.COM]
Sent: Thursday, March 05, 2009 11:42 AM
To: Jerome Dochez
Cc: embedded_at_glassfish.dev.java.net; Anil Gaur
Subject: [embedded] Re: Feedback Wanted: Embedded APIs for GFv3 Prelude
Thanks for the feedbacks.
Jerome Dochez wrote:
EmbeddedInfo is not generic enough, it asks for http ports but what
about if you need to add more listener, or even what about if you don't
want to open any port (like an embedded EJB Container).
I think the intent was to make it simple for typical use cases. People
can use CommandExecutor for more complicated configuration changes.
We need one consistent way of defining 0 to many http listeners and
ports.
Do you have a proposal for EmbeddedInfo? We can adjust it.
EmbeddedDeployer is also not generic enough, the scatteredWar concept
needs to be extended to an ScatteredArchive concept (which would map to
jar, war, rar and maybe even ear) and the deployScattered() methods need
to use that ScatteredArchive as a parameter. In fact, I am not sure why
we need a deployScattered() method all together, I think deploy() should
be enough and we should be smart enough to figure out what was passed to
us.
Agreed. We should use ScatteredArchive and deploy method if possible.
EmbeddedMain talks about using the uber jar, it should in fact be moved
into the glassfish.jar so that people can do the same thing using a
normal distribution (as they can already do today for most of the
features of that class, today I can do java -jar glassfish.jar foo.war).
There is no glassfish.jar in this case. Are you asking for supporting
"java -jar glassfish.jar foo.war" use case also? Please note that for
Prelude, we are not supporting the implanted use case yet. When we
support "implanted" we can certainly use glassfish.jar.
Server : why do we return the cataline Engine object ? I suppose this
would be removed once we integrate the new web container embedded APIs,
right ? If that's the case, we should not have here.
This is a bug. Byron/Jennifer: Could you please remove this?
So as a conclusion, this APIs is very targeted to war file deployment,
and we cannot hope to be able to extend it to support full V3 styles of
deployment and maintain backward compatibility.
Either we spend the time to make it right for embedded release or we
declare it as a non stable (with knowledge that it will extensively
change for v3 release).
Lets see what can be done. This is not throw away work.
--
Nazrul Islam - (408) 276-6468 - Sun Microsystems, Inc.
Jerome
On Mar 4, 2009, at 12:04 PM, Nazrul Islam wrote:
We are planning to wrap-up the development activities for GFv3
Prelude and move to GFv3 trunk. We would like your feedbacks on the
current APIs
<https://embedded-glassfish.dev.java.net/nonav/gf-embedded-api/apidocs/>
.
Background on Current APIs:
The APIs has gone through several iterations already. Thanks for
filing all the issues
<https://embedded-glassfish.dev.java.net/issues/buglist.cgi?Submit+query
=Submit+query&issue_type=DEFECT&issue_type=ENHANCEMENT&issue_type=FEATUR
E&issue_type=TASK&issue_type=PATCH&component=embedded-glassfish&subcompo
nent=API&issue_status=RESOLVED&issue_status=VERIFIED&issue_status=CLOSED
&version=current&email1=&emailtype1=exact&emailassigned_to1=1&email2=&em
ailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&changedin=
&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_
type=fulltext&long_desc=&long_desc_type=fulltext&issue_file_loc=&issue_f
ile_loc_type=fulltext&status_whiteboard=&status_whiteboard_type=fulltext
&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Issue+Num
ber> . The APIs has been reviewed internally also few times lately ([1
<https://embedded-glassfish.dev.java.net/issues/buglist.cgi?Submit+query
=Submit+query&issue_type=DEFECT&issue_type=ENHANCEMENT&issue_type=FEATUR
E&issue_type=TASK&issue_type=PATCH&component=embedded-glassfish&subcompo
nent=API&issue_status=RESOLVED&issue_status=VERIFIED&issue_status=CLOSED
&version=current&email1=&emailtype1=exact&emailassigned_to1=1&email2=ai1
09478&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&ch
angedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&sho
rt_desc_type=fulltext&long_desc=&long_desc_type=fulltext&issue_file_loc=
&issue_file_loc_type=fulltext&status_whiteboard=&status_whiteboard_type=
fulltext&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=I
ssue+Number> ], [2
<https://embedded-glassfish.dev.java.net/issues/show_bug.cgi?id=67> ],
[3 <https://embedded-glassfish.dev.java.net/issues/show_bug.cgi?id=86>
]) and is scheduled for a formal review at GlassFish architecture forum
on 3/16. Since we will be doing the webtier APIs on the trunk, for GFv3
Prelude we focused on basics first such as start/stop, configuration
management, etc. Refer to attached presentation for a brief overview of
the APIs.
Jerome: You mentioned that you may have some feedback. Please
let us know.
Thanks much.
References:
Javadocs:
https://embedded-glassfish.dev.java.net/nonav/gf-embedded-api/apidocs/
--
Nazrul Islam - (408) 276-6468 - Sun Microsystems, Inc.
<Embedded_GlassFish_API.odp>