You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Les Hazlewood <lh...@apache.org> on 2010/09/09 03:54:20 UTC

Shiro and OSGi

Hi team,

I'm writing an OSGi-based application, and I need the Shiro jars to
also be OSGi bundles.  Does anyone have any objections with me adding
the OSGi metadata to the Manifest files?  This would require changes
only to poms - not source code.  It is 100% backwards compatible.

This is what I would consider an interim step in making Shiro fully
OSGi friendly.  I think a more 'proper'/full OSGi approach would be
better suited for a Shiro 2.0 distribution since it would likely
require re-organizing some packages.  This would be close to the
_very_ old JSecurity 0.1 days, where there was an API jar and
implementation jars.  It is sort of similar to how the existing
'support' modules work today, but there would be segmentation in the
core module itself.  But of course, this type of work is further down
the line - like I said, a good candidate for 2.x work.

For now, I'd like to just get the metadata in the existing .jars.  Any
objections?

Cheers,

Les

Re: Shiro and OSGi

Posted by Alex Karasulu <ak...@apache.org>.
On Thu, Sep 9, 2010 at 5:16 AM, Craig L Russell <cr...@oracle.com>wrote:

> Hi Les,
>
> Take a look at the plugins that make jars into OSGi jars just by a bit of
> metadata.
>
> I've no objection if you add stuff like:
>
>      <plugin>
>        <groupId>org.apache.felix</groupId>
>        <artifactId>maven-bundle-plugin</artifactId>
>        <version>1.4.0</version>
>        <extensions>true</extensions>
>        <configuration>
>          <instructions>
>            <Export-Package>com.mysql.clusterj.tie.*</Export-Package>
>
>  <Import-Package>com.mysql.clusterj,com.mysql.clusterj.core.store,com.mysql.clusterj.core.query,com.mysql.clusterj.core.util,com.mysql.ndbjtie.mysql,com.mysql.ndbjtie.ndbapi</Import-Package>
>          </instructions>
>        </configuration>
>      </plugin>
>
> It's no bother to anyone not using OSGi and a huge help to people using it.
>
> Plus, it increases the use of "Apache uses Apache".
>
>
+1 thanks for this guys.

-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Re: Shiro and OSGi

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Sep 9, 2010, at 12:19 AM, Les Hazlewood wrote:

> I've committed all changes to the trunk (pom.xml changes only) - all
> library .jars (core, 3rd party support) have been made into OSGi
> bundles.  I didn't spend any time adding OSGi metadata to the samples
> modules since no one would use those as a dependency. Please update
> and take a peek if you're interested.
> 
> One issue:  I did not add any OSGi metadata to the shiro-all aggregate
> .jar.  Should we do this?  My assumption is that most people who are
> deploying OSGi applications, given OSGi's inclination towards
> modularity, wouldn't deploy the shiro-all .jar.
> 
> Does anyone have opinions on this one?

That makes sense to me.


Regards,
Alan


Re: Shiro and OSGi

Posted by Les Hazlewood <lh...@apache.org>.
I've committed all changes to the trunk (pom.xml changes only) - all
library .jars (core, 3rd party support) have been made into OSGi
bundles.  I didn't spend any time adding OSGi metadata to the samples
modules since no one would use those as a dependency. Please update
and take a peek if you're interested.

One issue:  I did not add any OSGi metadata to the shiro-all aggregate
.jar.  Should we do this?  My assumption is that most people who are
deploying OSGi applications, given OSGi's inclination towards
modularity, wouldn't deploy the shiro-all .jar.

Does anyone have opinions on this one?

Les

On Wed, Sep 8, 2010 at 10:21 PM, Craig L Russell
<cr...@oracle.com> wrote:
> Hi Les,
>
> On Sep 8, 2010, at 7:40 PM, Les Hazlewood wrote:
>
>> Hi Craig,
>>
>> Yep, this is precisely the stuff I want to add - I've been using the
>> maven-bundle-plugin and like it a lot.  I'll update the poms shortly
>> and we can review.
>>
>> A quick question though - I noticed in the example you gave that
>> version numbers are not specified on the export or import package
>> entries.  AIUI, this is a OSGi best practice to avoid version
>> discrepancies since not specifying an Import-Package version is
>> technically the same as saying version=[0.0.0, infinity).  Is there a
>> specific reason why the project you pasted from does not do this? (I'm
>> always trying to ensure my bundles are as 'proper' as they can be,
>> since OSGi versioning can be a nasty, nasty business - if I'm missing
>> something, I'm open to suggestions!)
>
> I'm afraid I'm not an expert on OSGi, so hopefully someone else can chime in
> with an opinion.
>
> Craig
>>
>> Thanks,
>>
>> Les.
>>
>> On Wed, Sep 8, 2010 at 7:16 PM, Craig L Russell
>> <cr...@oracle.com> wrote:
>>>
>>> Hi Les,
>>>
>>> Take a look at the plugins that make jars into OSGi jars just by a bit of
>>> metadata.
>>>
>>> I've no objection if you add stuff like:
>>>
>>>     <plugin>
>>>       <groupId>org.apache.felix</groupId>
>>>       <artifactId>maven-bundle-plugin</artifactId>
>>>       <version>1.4.0</version>
>>>       <extensions>true</extensions>
>>>       <configuration>
>>>         <instructions>
>>>           <Export-Package>com.mysql.clusterj.tie.*</Export-Package>
>>>
>>>
>>>  <Import-Package>com.mysql.clusterj,com.mysql.clusterj.core.store,com.mysql.clusterj.core.query,com.mysql.clusterj.core.util,com.mysql.ndbjtie.mysql,com.mysql.ndbjtie.ndbapi</Import-Package>
>>>         </instructions>
>>>       </configuration>
>>>     </plugin>
>>>
>>> It's no bother to anyone not using OSGi and a huge help to people using
>>> it.
>>>
>>> Plus, it increases the use of "Apache uses Apache".
>>>
>>> Craig
>>>
>>> On Sep 8, 2010, at 6:54 PM, Les Hazlewood wrote:
>>>
>>>> Hi team,
>>>>
>>>> I'm writing an OSGi-based application, and I need the Shiro jars to
>>>> also be OSGi bundles.  Does anyone have any objections with me adding
>>>> the OSGi metadata to the Manifest files?  This would require changes
>>>> only to poms - not source code.  It is 100% backwards compatible.
>>>>
>>>> This is what I would consider an interim step in making Shiro fully
>>>> OSGi friendly.  I think a more 'proper'/full OSGi approach would be
>>>> better suited for a Shiro 2.0 distribution since it would likely
>>>> require re-organizing some packages.  This would be close to the
>>>> _very_ old JSecurity 0.1 days, where there was an API jar and
>>>> implementation jars.  It is sort of similar to how the existing
>>>> 'support' modules work today, but there would be segmentation in the
>>>> core module itself.  But of course, this type of work is further down
>>>> the line - like I said, a good candidate for 2.x work.
>>>>
>>>> For now, I'd like to just get the metadata in the existing .jars.  Any
>>>> objections?
>>>>
>>>> Cheers,
>>>>
>>>> Les
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>

Re: Shiro and OSGi

Posted by Craig L Russell <cr...@oracle.com>.
Hi Les,

On Sep 8, 2010, at 7:40 PM, Les Hazlewood wrote:

> Hi Craig,
>
> Yep, this is precisely the stuff I want to add - I've been using the
> maven-bundle-plugin and like it a lot.  I'll update the poms shortly
> and we can review.
>
> A quick question though - I noticed in the example you gave that
> version numbers are not specified on the export or import package
> entries.  AIUI, this is a OSGi best practice to avoid version
> discrepancies since not specifying an Import-Package version is
> technically the same as saying version=[0.0.0, infinity).  Is there a
> specific reason why the project you pasted from does not do this? (I'm
> always trying to ensure my bundles are as 'proper' as they can be,
> since OSGi versioning can be a nasty, nasty business - if I'm missing
> something, I'm open to suggestions!)

I'm afraid I'm not an expert on OSGi, so hopefully someone else can  
chime in with an opinion.

Craig
>
> Thanks,
>
> Les.
>
> On Wed, Sep 8, 2010 at 7:16 PM, Craig L Russell
> <cr...@oracle.com> wrote:
>> Hi Les,
>>
>> Take a look at the plugins that make jars into OSGi jars just by a  
>> bit of
>> metadata.
>>
>> I've no objection if you add stuff like:
>>
>>      <plugin>
>>        <groupId>org.apache.felix</groupId>
>>        <artifactId>maven-bundle-plugin</artifactId>
>>        <version>1.4.0</version>
>>        <extensions>true</extensions>
>>        <configuration>
>>          <instructions>
>>            <Export-Package>com.mysql.clusterj.tie.*</Export-Package>
>>
>>  <Import- 
>> Package 
>> > 
>> com 
>> .mysql 
>> .clusterj 
>> ,com 
>> .mysql 
>> .clusterj 
>> .core 
>> .store 
>> ,com 
>> .mysql 
>> .clusterj 
>> .core 
>> .query 
>> ,com 
>> .mysql 
>> .clusterj 
>> .core.util,com.mysql.ndbjtie.mysql,com.mysql.ndbjtie.ndbapi</Import- 
>> Package>
>>          </instructions>
>>        </configuration>
>>      </plugin>
>>
>> It's no bother to anyone not using OSGi and a huge help to people  
>> using it.
>>
>> Plus, it increases the use of "Apache uses Apache".
>>
>> Craig
>>
>> On Sep 8, 2010, at 6:54 PM, Les Hazlewood wrote:
>>
>>> Hi team,
>>>
>>> I'm writing an OSGi-based application, and I need the Shiro jars to
>>> also be OSGi bundles.  Does anyone have any objections with me  
>>> adding
>>> the OSGi metadata to the Manifest files?  This would require changes
>>> only to poms - not source code.  It is 100% backwards compatible.
>>>
>>> This is what I would consider an interim step in making Shiro fully
>>> OSGi friendly.  I think a more 'proper'/full OSGi approach would be
>>> better suited for a Shiro 2.0 distribution since it would likely
>>> require re-organizing some packages.  This would be close to the
>>> _very_ old JSecurity 0.1 days, where there was an API jar and
>>> implementation jars.  It is sort of similar to how the existing
>>> 'support' modules work today, but there would be segmentation in the
>>> core module itself.  But of course, this type of work is further  
>>> down
>>> the line - like I said, a good candidate for 2.x work.
>>>
>>> For now, I'd like to just get the metadata in the existing .jars.   
>>> Any
>>> objections?
>>>
>>> Cheers,
>>>
>>> Les

Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!


Re: Shiro and OSGi

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Sep 8, 2010, at 7:40 PM, Les Hazlewood wrote:

> Hi Craig,
> 
> Yep, this is precisely the stuff I want to add - I've been using the
> maven-bundle-plugin and like it a lot.  I'll update the poms shortly
> and we can review.
> 
> A quick question though - I noticed in the example you gave that
> version numbers are not specified on the export or import package
> entries.  AIUI, this is a OSGi best practice to avoid version
> discrepancies since not specifying an Import-Package version is
> technically the same as saying version=[0.0.0, infinity).  Is there a
> specific reason why the project you pasted from does not do this? (I'm
> always trying to ensure my bundles are as 'proper' as they can be,
> since OSGi versioning can be a nasty, nasty business - if I'm missing
> something, I'm open to suggestions!)


You may want to read:

http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf


Regards

Re: Shiro and OSGi

Posted by Les Hazlewood <lh...@apache.org>.
Hi Craig,

Yep, this is precisely the stuff I want to add - I've been using the
maven-bundle-plugin and like it a lot.  I'll update the poms shortly
and we can review.

A quick question though - I noticed in the example you gave that
version numbers are not specified on the export or import package
entries.  AIUI, this is a OSGi best practice to avoid version
discrepancies since not specifying an Import-Package version is
technically the same as saying version=[0.0.0, infinity).  Is there a
specific reason why the project you pasted from does not do this? (I'm
always trying to ensure my bundles are as 'proper' as they can be,
since OSGi versioning can be a nasty, nasty business - if I'm missing
something, I'm open to suggestions!)

Thanks,

Les.

On Wed, Sep 8, 2010 at 7:16 PM, Craig L Russell
<cr...@oracle.com> wrote:
> Hi Les,
>
> Take a look at the plugins that make jars into OSGi jars just by a bit of
> metadata.
>
> I've no objection if you add stuff like:
>
>      <plugin>
>        <groupId>org.apache.felix</groupId>
>        <artifactId>maven-bundle-plugin</artifactId>
>        <version>1.4.0</version>
>        <extensions>true</extensions>
>        <configuration>
>          <instructions>
>            <Export-Package>com.mysql.clusterj.tie.*</Export-Package>
>
>  <Import-Package>com.mysql.clusterj,com.mysql.clusterj.core.store,com.mysql.clusterj.core.query,com.mysql.clusterj.core.util,com.mysql.ndbjtie.mysql,com.mysql.ndbjtie.ndbapi</Import-Package>
>          </instructions>
>        </configuration>
>      </plugin>
>
> It's no bother to anyone not using OSGi and a huge help to people using it.
>
> Plus, it increases the use of "Apache uses Apache".
>
> Craig
>
> On Sep 8, 2010, at 6:54 PM, Les Hazlewood wrote:
>
>> Hi team,
>>
>> I'm writing an OSGi-based application, and I need the Shiro jars to
>> also be OSGi bundles.  Does anyone have any objections with me adding
>> the OSGi metadata to the Manifest files?  This would require changes
>> only to poms - not source code.  It is 100% backwards compatible.
>>
>> This is what I would consider an interim step in making Shiro fully
>> OSGi friendly.  I think a more 'proper'/full OSGi approach would be
>> better suited for a Shiro 2.0 distribution since it would likely
>> require re-organizing some packages.  This would be close to the
>> _very_ old JSecurity 0.1 days, where there was an API jar and
>> implementation jars.  It is sort of similar to how the existing
>> 'support' modules work today, but there would be segmentation in the
>> core module itself.  But of course, this type of work is further down
>> the line - like I said, a good candidate for 2.x work.
>>
>> For now, I'd like to just get the metadata in the existing .jars.  Any
>> objections?
>>
>> Cheers,
>>
>> Les

Re: Shiro and OSGi

Posted by Craig L Russell <cr...@oracle.com>.
Hi Les,

Take a look at the plugins that make jars into OSGi jars just by a bit  
of metadata.

I've no objection if you add stuff like:

       <plugin>
         <groupId>org.apache.felix</groupId>
         <artifactId>maven-bundle-plugin</artifactId>
         <version>1.4.0</version>
         <extensions>true</extensions>
         <configuration>
           <instructions>
             <Export-Package>com.mysql.clusterj.tie.*</Export-Package>
             <Import- 
Package 
 > 
com 
.mysql 
.clusterj 
,com 
.mysql 
.clusterj 
.core 
.store 
,com 
.mysql 
.clusterj 
.core 
.query 
,com 
.mysql 
.clusterj.core.util,com.mysql.ndbjtie.mysql,com.mysql.ndbjtie.ndbapi</ 
Import-Package>
           </instructions>
         </configuration>
       </plugin>

It's no bother to anyone not using OSGi and a huge help to people  
using it.

Plus, it increases the use of "Apache uses Apache".

Craig

On Sep 8, 2010, at 6:54 PM, Les Hazlewood wrote:

> Hi team,
>
> I'm writing an OSGi-based application, and I need the Shiro jars to
> also be OSGi bundles.  Does anyone have any objections with me adding
> the OSGi metadata to the Manifest files?  This would require changes
> only to poms - not source code.  It is 100% backwards compatible.
>
> This is what I would consider an interim step in making Shiro fully
> OSGi friendly.  I think a more 'proper'/full OSGi approach would be
> better suited for a Shiro 2.0 distribution since it would likely
> require re-organizing some packages.  This would be close to the
> _very_ old JSecurity 0.1 days, where there was an API jar and
> implementation jars.  It is sort of similar to how the existing
> 'support' modules work today, but there would be segmentation in the
> core module itself.  But of course, this type of work is further down
> the line - like I said, a good candidate for 2.x work.
>
> For now, I'd like to just get the metadata in the existing .jars.  Any
> objections?
>
> Cheers,
>
> Les

Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!