directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [API] Experimenting OSGI fragments to solve the extensibility issue
Date Thu, 20 Oct 2011 11:23:14 GMT
I think the original point of fragments is more extending a bundle rather
than solving split package issues (though, that's a common use case now, but
more as a hack when porting non osgi libraries to osgi), see [1].  So imho,
fragments are not hacks, but the real use cases are not very common.

The api use case is a good one for fragments imho, especially if you want
the api to be easily used in a non osgi environment, such as web apps.
It's a good use case because what you really want is just to make sure the
needed classes are available to the classloader, you have no real service
dependencies.   I'm sure that could be modelled using services, but that
looks like a non intuitive solution to me, especially if your entry point is
the class name.

The main problem I see with using services is really that you will need two
different logics (one when inside the osgi container and one outside), which
means writing those extensions will be more complicated too if you need to
support both environment.   Also, my experience in writing such dual support
is that you sometime find problems when people start embedding those
libraries in a war and deploy them in osgi: you're in a mix situation where
the jars are deployed in osgi, but not as real bundles.

[1]
http://books.google.fr/books?id=ROGxuH3ffVsC&pg=PA153&lpg=PA153&dq=fragment+purpose+osgi&source=bl&ots=WuIZ5WKU7q&sig=DMkOX8Z34DW5c4Lm7FnIrwEn2gQ&hl=fr&ei=vP6fTqvZH43n-gaVmJykBQ&sa=X&oi=book_result&ct=result&resnum=10&ved=0CH8Q6AEwCQ#v=onepage&q=fragment%20purpose%20osgi&f=false

On Thu, Oct 20, 2011 at 12:33, Alex Karasulu <akarasulu@apache.org> wrote:

> On Thu, Oct 20, 2011 at 1:18 PM, Emmanuel Lecharny <elecharny@gmail.com>wrote:
>
>> On 10/20/11 12:06 PM, Alex Karasulu wrote:
>>
>>> On Thu, Oct 20, 2011 at 12:43 PM, Guillaume Nodet<gnodet@gmail.com>
>>>  wrote:
>>>
>>>  I think you first need to define your constraints and what you want to
>>>> focus on.
>>>>
>>>>  Excellent point so let's recap a little. In the API we have certain
>>> functionality extension points:
>>>
>>> 1). Codec Extensions
>>>
>>> These extension points are for adding support LDAP extended operation and
>>> LDAP control support so the API can handle them explicitly as structured
>>> elements rather than opaque unstructured data. This is pretty well
>>> defined
>>> and understood by the Directory Team I think and we opted for using a
>>> non-OSGi based ClassLoader mechanism. If this has changed please correct
>>> me.
>>>
>>
>
>>  Those codec are not supposed to be written by external users.
>
>
> I disagree with the this statement above. If codec extensions are not to be
> written by non-API committers then why are we going to all this trouble
> class loading them and making them pluggable?
>
> Our users might want to implement a control using our API for an LDAP
> server which exposes controls or extended operations which we have not
> supported. This provides a means for them to extend our API and achieve
> their goals.
>
>
>> This is just fine to keep them as they are. We can even make them plain
>> OSGi services at some point. In any case, this is a non issue.
>>
>>
> This I agree with because it allows extension as-is. It's a clean straight
> forward solution for now.
>
>
>>
>>> 2). LDAP Schema
>>>
>>> Now from what I understand enabling new schema on clients via the API is
>>> the
>>> main issue introducing additional constraints requiring us to consider
>>> the
>>> use of fragments.
>>>
>>> Is this correct?
>>>
>> Correct, sir !
>>
>>
> :-D
>
>
>>
>>> Another part of the problem is making this work in both a non-OSGi client
>>> side API environment in addition to an OSGi based environment in both
>>> ApacheDS and Studio.
>>>
>>> Is this correct?
>>>
>> Aye aye, sir !
>>
>>
> Since when was I knighted by the Queen :-D.
>
>
>>
>>> Also we had some conversations in the past of not actually using OSGi to
>>> load schema into the API. Sorry I don't have a email reference to the
>>> past
>>> thread. Did our position change on this topic in the recent past?
>>>
>> Nope, this is exactly the problem we have : be able to class-load those
>> schema extensions the ol' Java way (ie, class.forName() )
>>
>>
> Sorry to beat a dead horse here but OK so we are not trying to use OSGi for
> loading schema in all environments: client API, apacheds, and studio?
>
>
>>
>>> If you want someone to be able to write a jar to extend the api which
>>> will
>>>
>>>> work in a non osgi environment and (with minimal changes) in an osgi
>>>> environment, go for fragments.
>>>>
>>>>  Forgive me, but the fragment approach seems like a hack. Fragments were
>>> created in OSGi to handle intractable problems with split packages where
>>> you
>>> had no way to merge the split. Now we're using it as a main stream
>>> feature
>>> to work around these hairy issues. Please note that I am not saying we
>>> should abandon it, just playing devil's advocate here. We obviously need
>>> more thought on the constraints which you've made very apparent here in
>>> your
>>> post. Thanks for it.
>>>
>> Seems currently to be the only path we can use. We may ask on Felix's
>> mailing list to see if there is some other way, but I trust Guillaume here.
>>
>>
> This is not a trust issue with anyone. It's a matter of exploration and
> lack of being up to date on my part. Hope no one misinterprets my questions
> as a lack of trust. I'm finding discrepancies in what I learned in the past
> with the proposed direction today and asking about it.
>
>
>>
>>> If you want to go a cleaner osgi way, go for services, but forget about
>>>
>>>> class names in the schema directly, and you need to define two different
>>>> ways, one for osgi and one in a non osgi environment (as you won't have
>>>> osgi
>>>> services at all in a flat classloader).
>>>>
>>>> It's all about trade-offs.
>>>>
>>>>
>>>>  Right.
>>>
>> Yeah...
>>
>>
>>
>>>
>>>  When talking with Emmanuel this week, it seems to me that for the api,
>>>> extending the api was not a very common operation and did not really
>>>> require
>>>> the osgi dynamism.  Fragments are perfect for those simple use cases.
>>>>
>>>>  Yes but the extension should not happen in the same package. Hence
>>> we're
>>> using this feature for something it was not intended for. Again just
>>> pointing this out, not saying it's not ideal. Perhaps this is fact is not
>>> at
>>> all that important in the end.
>>>
>>
>> can you be a bit more explicit here, for people like me who ae
>> semi-OSGi-agnostic ?
>> (damn, I *knew* I should have jumped into the OSGi wagon one year ago, at
>> least... That's the problem when beig lazzy :/ )
>>
>>
> Well I jumped on the wagon several times and fell off repeatedly without
> concrete application opportunities to solidify this knowledge. Guillaume is
> perhaps the most experienced having used OSGi practically for years now.
>
> From my limited understanding the fragments feature was created to handle
> situations when you had split packages but could not merge those packages
> because you did not have access to the code or some sh*t like that.
>
> These extensions should not be in the same package space. Those adding
> schema or other extensions should not be adding them into the same packages
> used by the API. In that case my logic leads me to the question: why use
> fragments?
>
>
>>
>>
>>>
>>>  But for sure, if you ask an OSGi purist, the recommandation will be to
>>>> not
>>>> use fragments.
>>>>
>>>>
>>>>  Right and maybe we should not be purists ;).
>>>
>>
>> Purity is good for virgins. We aren't...
>>
>>
> Heh, yeah but sometimes non-virgins like to look like virgins :-D.
>
> --
> Best Regards,
> -- Alex
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message