Hi,
I have already acknowledged that GlassFish could be benefited from the
OSGi shell extensions.
I don't see us bundling blueprint bundles, because we expect our users
to use CDI for their dependency injection. It works well in their hybrid
apps and is easier to use IMHO. Blueprint works well with CDI and they
both can be used in the same bundle. You are expecting the same
component to be managed by two IoC containers which is rarely the case.
As I have already told you, if blueprint is extensible, we can certainly
evaluate the possibility of writing a portable CDI extension to perform
injections in a blueprint component. You are most welcome to file an RFE
to this effect in GlassFish.
I don't understand this logging requirement. How is this unified log API
from Karaf any different from something like slf4j? Some of our extenral
bundles use slf4j, but we configure them to use slf4j/jdk binding so
that the log messages produced by them go to our server.log. I see a
number of projects using slf4j - not that I am great fan of it. Is there
a new log API that Karaf proposes? If so, I don't see GlassFish ever
migrating to it. We have decided to use JDK logging APIs in our own
bundles and as the logging backend. We expect other logging frameworks
to provide bindings to JDK logging and many do.
Striking a right balance is not easy. A lot of GlassFish users don't
know about OSGi, so they hardly care about these things. The ones who
are familiar with OSGi know how to add these extensions. If you want to
see some of these extensions by default, please file some RFEs in
GlassFish JIRA so we can consider them when we plan our releases.
Thanks for this discussion,
Sahoo
On Thursday 20 October 2011 07:31 PM, Jean-Philippe Clement wrote:
Well,
* "GF already has OSGi Gogo shell": I only succeeded in having a very
basic shell with few commands and without any mention to Blueprint status
* "GlassFish has decided to use JDK logging": sure, but you have to
cope with existing bundles which are far from being 100% JDK logging -
Karaf logging unifies major log APIs
...and the integration of Blueprint which is part of OSGi 4.2
standard: it has to be manually added to GlassFish and, in even in
that case, it would not be integrated with CDI.
Kind regards,
Jean-Philippe
Quoting Sahoo <[email protected]>:
Let me understand better. GF already has OSGi Gogo shell and Felix Web
console.
It has its security layer using which user can define their security
realms, jaas providers, etc (these are all required as per Java EE spec
anyway).
What kind of provisioning does karaf provide? GlassFish uses
FileInstall in addition to a configurable list of bundles. OBR will be
integrated in next release. The additional fileinstall extensions from
karaf can be used in GlassFish as well. Yes, we can certainly consider
bundling some of them in GlassFish as well.
GlassFish has decided to use JDK logging and has its legacy around
logging.
We have a very sophisticated administration model to support clustering
and fail over features. Although we don't use OSGi config admin, our
administration model uses a centralized XML file as configuration store
and we provide both CLI and GUI to update the configuration. All
administration of GlassFish can be done using REST APIs in addition to
CLIs. GlassFish uses ssh to to communicate with multiple hosts that are
part of a cluster.
So, what additional benefits will I get by switching to Karaf? Yes,
some of the advanced shell stuff in Karaf is worth integrating in
GlassFish. We can consider using some of those in GlassFish as well.
What else?
Thanks for the suggestion,
Sahoo
ps: BTW, how did your experiment of using some of the karaf bundles in
GlassFish go?
On Friday 14 October 2011 09:08 PM, Jean-Philippe Clement wrote:
Yes! Could be great!!!
So it would include Blueprint as well... talking about Blueprint,
it could be nice to have a Blueprint constructed instance with an
injection from CGI, for instance to get a Queue, JPA...
But as it is now, I think it could do the job: CGI for low layers
(DAO...) and Blueprint for other ones.
Do you think it could be possible to base GlassFish on Karaf
instead of Felix?
Kind regards,
Jean-Philippe
Quoting Charles Moulliard <[email protected]>:
Hi Sahoo,
It could be interesting that you consider in the future to use Apache
Karaf (like Geronimo, ServiceMix, ...) as the OSGI platform of
GlassFish to provide the great features that we have in Karaf
(provisioning, console, ssh, jaas for security, pax-logging to unify
the log Api, ....) ?
Regards,
Charles
On Fri, Oct 14, 2011 at 3:22 PM, Sahoo <[email protected]>
wrote:
On Friday 14 October 2011 05:29 PM, Jean-Philippe Clement wrote:
Note that Blueprint as a separate bundle interferes with
GlassFish CGI.
Either injection with Blueprint, or with CGI but not "mixed mode".
Let's clarify "mixed mode." I have not really used them together,
but my
understanding is one can have components managed by both CDI and
blueprints
in the same bundle in GlassFish. What one can't have is the same
component
instance being managed by both the containers. GlassFish/CDI
extension even
allows CDI components to be injected with OSGi services (which
automatically
include blueprint components). If you see different behavior, let
us know so
that we can understand what's going on and cam fix it if need be.
Thanks,
Sahoo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
