felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sahoo <sanjeeb.sa...@oracle.com>
Subject Re: Add GlassFish mode to Karaf?
Date Thu, 20 Oct 2011 18:39:03 GMT
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 <sanjeeb.sahoo@oracle.com>:
>
>> 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 <cmoulliard@gmail.com>:
>>>
>>>> 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 <sanjeeb.sahoo@oracle.com> 
>>>> 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: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message