You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Charles Moulliard <cm...@gmail.com> on 2011/01/10 22:46:45 UTC
Register customer librairies like we do for JRE lib
Hi,
I would like to know if we have a property that we can setup to
register additional jar librairies (defined in a client folder
directory) like we do for JRE runtime libraries and expose them as
packages ? If this is not the case, could the hot "deploy" folder be
the alternative ?
Regards,
Charles Moulliard
Sr. Principal Solution Architect - FuseSource
Apache Committer
Blog : http://cmoulliard.blogspot.com
Twitter : http://twitter.com/cmoulliard
Linkedin : http://www.linkedin.com/in/charlesmoulliard
Skype: cmoulliard
Re: Register customer librairies like we do for JRE lib
Posted by Achim Nierbeck <bc...@googlemail.com>.
+1 for the idea of a hot deploy for jars with auto wrap
2011/1/11 Adrian Trenaman <tr...@progress.com>:
> Hmmm.
>
> I think I recall Guillaume saying that you could achieve this by just
> dropping them into a lib/ext directory?
>
> However, I prefer the idea of a 'Jar' deployer: if you drop a plain JAR into
> the deploy directory, then it should depoy using wrap (and making all
> dependencies marked for optional resolution to assist ease of use).
>
> Best,
> Ade.
>
> On 10/01/2011 21:46, Charles Moulliard wrote:
>>
>> Hi,
>>
>> I would like to know if we have a property that we can setup to
>> register additional jar librairies (defined in a client folder
>> directory) like we do for JRE runtime libraries and expose them as
>> packages ? If this is not the case, could the hot "deploy" folder be
>> the alternative ?
>>
>> Regards,
>>
>> Charles Moulliard
>>
>> Sr. Principal Solution Architect - FuseSource
>> Apache Committer
>>
>> Blog : http://cmoulliard.blogspot.com
>> Twitter : http://twitter.com/cmoulliard
>> Linkedin : http://www.linkedin.com/in/charlesmoulliard
>> Skype: cmoulliard
>
> --
> Adrian Trenaman, Sr. Principal Solution Architect
> FuseSource
> Phone: +353-86-6051026
> Email: trenaman@fusesource.com
> Web: http://trenaman.blogspot.com, http://fusesource.com
> Twitter: adrian_trenaman
>
>
Re: Register customer librairies like we do for JRE lib
Posted by Andreas Pieber <an...@gmail.com>.
sounds good to me; I've created KARAF-380 to keep track of this feature
kind regards,
andreas
On Tue, Jan 11, 2011 at 05:40:49AM -0800, Guillaume Nodet wrote:
> Yeah, I was considering that. Using the OSGi ranking attribute on services
> should be sufficient in order to keep them ordered.
>
> And checking the 'jar' extension would clearly remove most of the bad
> situations for that case.
>
> On Tue, Jan 11, 2011 at 05:24, Andreas Pieber <an...@gmail.com> wrote:
>
> > I also think so. We "simply" have to add the ability to order deployer.
> > This way
> > we can savely exclude such situation as "all of them having the same
> > ending".
> >
> > kind regards,
> > andreas
> >
> > On Tue, Jan 11, 2011 at 01:15:56PM +0000, Adrian Trenaman wrote:
> > > I think I'd go with it like this:
> > >
> > > If we detect a file in the deploy/ directory with the extension
> > > '.jar', AND the JAR's manifest does NOT contain any OSGi headers,
> > > THEN we assume that it's a plain-old-jar, and perform an auto-wrap.
> > >
> > > Sounds pretty safe (and very usable!) to me, no?
> > >
> > > On 11/01/2011 13:04, Guillaume Nodet wrote:
> > > >That could be a good idea, but I'm not sure how to identify soemthing by
> > the
> > > >negative without screwing the whole thing.
> > > >I mean a war is a jar too, a kar is a zip file, a jbi archive is also a
> > zip
> > > >file. It would be a bit of a catch-everything, so I'm not really sure
> > if
> > > >that would work well.
> > > >
> > > >On Tue, Jan 11, 2011 at 01:51, Adrian Trenaman<trenaman@progress.com
> > >wrote:
> > > >
> > > >>Hmmm.
> > > >>
> > > >>I think I recall Guillaume saying that you could achieve this by just
> > > >>dropping them into a lib/ext directory?
> > > >>
> > > >>However, I prefer the idea of a 'Jar' deployer: if you drop a plain JAR
> > > >>into the deploy directory, then it should depoy using wrap (and making
> > all
> > > >>dependencies marked for optional resolution to assist ease of use).
> > > >>
> > > >>Best,
> > > >>Ade.
> > > >>
> > > >>
> > > >>On 10/01/2011 21:46, Charles Moulliard wrote:
> > > >>
> > > >>>Hi,
> > > >>>
> > > >>>I would like to know if we have a property that we can setup to
> > > >>>register additional jar librairies (defined in a client folder
> > > >>>directory) like we do for JRE runtime libraries and expose them as
> > > >>>packages ? If this is not the case, could the hot "deploy" folder be
> > > >>>the alternative ?
> > > >>>
> > > >>>Regards,
> > > >>>
> > > >>>Charles Moulliard
> > > >>>
> > > >>>Sr. Principal Solution Architect - FuseSource
> > > >>>Apache Committer
> > > >>>
> > > >>>Blog : http://cmoulliard.blogspot.com
> > > >>>Twitter : http://twitter.com/cmoulliard
> > > >>>Linkedin : http://www.linkedin.com/in/charlesmoulliard
> > > >>>Skype: cmoulliard
> > > >>>
> > > >>--
> > > >>Adrian Trenaman, Sr. Principal Solution Architect
> > > >>FuseSource
> > > >>Phone: +353-86-6051026
> > > >>Email: trenaman@fusesource.com
> > > >>Web: http://trenaman.blogspot.com, http://fusesource.com
> > > >>Twitter: adrian_trenaman
> > > >>
> > > >>
> > > >
> > >
> > > --
> > > Adrian Trenaman, Sr. Principal Solution Architect
> > > FuseSource
> > > Phone: +353-86-6051026
> > > Email: trenaman@fusesource.com
> > > Web: http://trenaman.blogspot.com, http://fusesource.com
> > > Twitter: adrian_trenaman
> > >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Register customer librairies like we do for JRE lib
Posted by Guillaume Nodet <gn...@gmail.com>.
Yeah, I was considering that. Using the OSGi ranking attribute on services
should be sufficient in order to keep them ordered.
And checking the 'jar' extension would clearly remove most of the bad
situations for that case.
On Tue, Jan 11, 2011 at 05:24, Andreas Pieber <an...@gmail.com> wrote:
> I also think so. We "simply" have to add the ability to order deployer.
> This way
> we can savely exclude such situation as "all of them having the same
> ending".
>
> kind regards,
> andreas
>
> On Tue, Jan 11, 2011 at 01:15:56PM +0000, Adrian Trenaman wrote:
> > I think I'd go with it like this:
> >
> > If we detect a file in the deploy/ directory with the extension
> > '.jar', AND the JAR's manifest does NOT contain any OSGi headers,
> > THEN we assume that it's a plain-old-jar, and perform an auto-wrap.
> >
> > Sounds pretty safe (and very usable!) to me, no?
> >
> > On 11/01/2011 13:04, Guillaume Nodet wrote:
> > >That could be a good idea, but I'm not sure how to identify soemthing by
> the
> > >negative without screwing the whole thing.
> > >I mean a war is a jar too, a kar is a zip file, a jbi archive is also a
> zip
> > >file. It would be a bit of a catch-everything, so I'm not really sure
> if
> > >that would work well.
> > >
> > >On Tue, Jan 11, 2011 at 01:51, Adrian Trenaman<trenaman@progress.com
> >wrote:
> > >
> > >>Hmmm.
> > >>
> > >>I think I recall Guillaume saying that you could achieve this by just
> > >>dropping them into a lib/ext directory?
> > >>
> > >>However, I prefer the idea of a 'Jar' deployer: if you drop a plain JAR
> > >>into the deploy directory, then it should depoy using wrap (and making
> all
> > >>dependencies marked for optional resolution to assist ease of use).
> > >>
> > >>Best,
> > >>Ade.
> > >>
> > >>
> > >>On 10/01/2011 21:46, Charles Moulliard wrote:
> > >>
> > >>>Hi,
> > >>>
> > >>>I would like to know if we have a property that we can setup to
> > >>>register additional jar librairies (defined in a client folder
> > >>>directory) like we do for JRE runtime libraries and expose them as
> > >>>packages ? If this is not the case, could the hot "deploy" folder be
> > >>>the alternative ?
> > >>>
> > >>>Regards,
> > >>>
> > >>>Charles Moulliard
> > >>>
> > >>>Sr. Principal Solution Architect - FuseSource
> > >>>Apache Committer
> > >>>
> > >>>Blog : http://cmoulliard.blogspot.com
> > >>>Twitter : http://twitter.com/cmoulliard
> > >>>Linkedin : http://www.linkedin.com/in/charlesmoulliard
> > >>>Skype: cmoulliard
> > >>>
> > >>--
> > >>Adrian Trenaman, Sr. Principal Solution Architect
> > >>FuseSource
> > >>Phone: +353-86-6051026
> > >>Email: trenaman@fusesource.com
> > >>Web: http://trenaman.blogspot.com, http://fusesource.com
> > >>Twitter: adrian_trenaman
> > >>
> > >>
> > >
> >
> > --
> > Adrian Trenaman, Sr. Principal Solution Architect
> > FuseSource
> > Phone: +353-86-6051026
> > Email: trenaman@fusesource.com
> > Web: http://trenaman.blogspot.com, http://fusesource.com
> > Twitter: adrian_trenaman
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Register customer librairies like we do for JRE lib
Posted by Andreas Pieber <an...@gmail.com>.
I also think so. We "simply" have to add the ability to order deployer. This way
we can savely exclude such situation as "all of them having the same ending".
kind regards,
andreas
On Tue, Jan 11, 2011 at 01:15:56PM +0000, Adrian Trenaman wrote:
> I think I'd go with it like this:
>
> If we detect a file in the deploy/ directory with the extension
> '.jar', AND the JAR's manifest does NOT contain any OSGi headers,
> THEN we assume that it's a plain-old-jar, and perform an auto-wrap.
>
> Sounds pretty safe (and very usable!) to me, no?
>
> On 11/01/2011 13:04, Guillaume Nodet wrote:
> >That could be a good idea, but I'm not sure how to identify soemthing by the
> >negative without screwing the whole thing.
> >I mean a war is a jar too, a kar is a zip file, a jbi archive is also a zip
> >file. It would be a bit of a catch-everything, so I'm not really sure if
> >that would work well.
> >
> >On Tue, Jan 11, 2011 at 01:51, Adrian Trenaman<tr...@progress.com>wrote:
> >
> >>Hmmm.
> >>
> >>I think I recall Guillaume saying that you could achieve this by just
> >>dropping them into a lib/ext directory?
> >>
> >>However, I prefer the idea of a 'Jar' deployer: if you drop a plain JAR
> >>into the deploy directory, then it should depoy using wrap (and making all
> >>dependencies marked for optional resolution to assist ease of use).
> >>
> >>Best,
> >>Ade.
> >>
> >>
> >>On 10/01/2011 21:46, Charles Moulliard wrote:
> >>
> >>>Hi,
> >>>
> >>>I would like to know if we have a property that we can setup to
> >>>register additional jar librairies (defined in a client folder
> >>>directory) like we do for JRE runtime libraries and expose them as
> >>>packages ? If this is not the case, could the hot "deploy" folder be
> >>>the alternative ?
> >>>
> >>>Regards,
> >>>
> >>>Charles Moulliard
> >>>
> >>>Sr. Principal Solution Architect - FuseSource
> >>>Apache Committer
> >>>
> >>>Blog : http://cmoulliard.blogspot.com
> >>>Twitter : http://twitter.com/cmoulliard
> >>>Linkedin : http://www.linkedin.com/in/charlesmoulliard
> >>>Skype: cmoulliard
> >>>
> >>--
> >>Adrian Trenaman, Sr. Principal Solution Architect
> >>FuseSource
> >>Phone: +353-86-6051026
> >>Email: trenaman@fusesource.com
> >>Web: http://trenaman.blogspot.com, http://fusesource.com
> >>Twitter: adrian_trenaman
> >>
> >>
> >
>
> --
> Adrian Trenaman, Sr. Principal Solution Architect
> FuseSource
> Phone: +353-86-6051026
> Email: trenaman@fusesource.com
> Web: http://trenaman.blogspot.com, http://fusesource.com
> Twitter: adrian_trenaman
>
Re: Register customer librairies like we do for JRE lib
Posted by Adrian Trenaman <tr...@progress.com>.
I think I'd go with it like this:
If we detect a file in the deploy/ directory with the extension '.jar',
AND the JAR's manifest does NOT contain any OSGi headers, THEN we assume
that it's a plain-old-jar, and perform an auto-wrap.
Sounds pretty safe (and very usable!) to me, no?
On 11/01/2011 13:04, Guillaume Nodet wrote:
> That could be a good idea, but I'm not sure how to identify soemthing by the
> negative without screwing the whole thing.
> I mean a war is a jar too, a kar is a zip file, a jbi archive is also a zip
> file. It would be a bit of a catch-everything, so I'm not really sure if
> that would work well.
>
> On Tue, Jan 11, 2011 at 01:51, Adrian Trenaman<tr...@progress.com>wrote:
>
>> Hmmm.
>>
>> I think I recall Guillaume saying that you could achieve this by just
>> dropping them into a lib/ext directory?
>>
>> However, I prefer the idea of a 'Jar' deployer: if you drop a plain JAR
>> into the deploy directory, then it should depoy using wrap (and making all
>> dependencies marked for optional resolution to assist ease of use).
>>
>> Best,
>> Ade.
>>
>>
>> On 10/01/2011 21:46, Charles Moulliard wrote:
>>
>>> Hi,
>>>
>>> I would like to know if we have a property that we can setup to
>>> register additional jar librairies (defined in a client folder
>>> directory) like we do for JRE runtime libraries and expose them as
>>> packages ? If this is not the case, could the hot "deploy" folder be
>>> the alternative ?
>>>
>>> Regards,
>>>
>>> Charles Moulliard
>>>
>>> Sr. Principal Solution Architect - FuseSource
>>> Apache Committer
>>>
>>> Blog : http://cmoulliard.blogspot.com
>>> Twitter : http://twitter.com/cmoulliard
>>> Linkedin : http://www.linkedin.com/in/charlesmoulliard
>>> Skype: cmoulliard
>>>
>> --
>> Adrian Trenaman, Sr. Principal Solution Architect
>> FuseSource
>> Phone: +353-86-6051026
>> Email: trenaman@fusesource.com
>> Web: http://trenaman.blogspot.com, http://fusesource.com
>> Twitter: adrian_trenaman
>>
>>
>
--
Adrian Trenaman, Sr. Principal Solution Architect
FuseSource
Phone: +353-86-6051026
Email: trenaman@fusesource.com
Web: http://trenaman.blogspot.com, http://fusesource.com
Twitter: adrian_trenaman
Re: Register customer librairies like we do for JRE lib
Posted by Guillaume Nodet <gn...@gmail.com>.
That could be a good idea, but I'm not sure how to identify soemthing by the
negative without screwing the whole thing.
I mean a war is a jar too, a kar is a zip file, a jbi archive is also a zip
file. It would be a bit of a catch-everything, so I'm not really sure if
that would work well.
On Tue, Jan 11, 2011 at 01:51, Adrian Trenaman <tr...@progress.com>wrote:
> Hmmm.
>
> I think I recall Guillaume saying that you could achieve this by just
> dropping them into a lib/ext directory?
>
> However, I prefer the idea of a 'Jar' deployer: if you drop a plain JAR
> into the deploy directory, then it should depoy using wrap (and making all
> dependencies marked for optional resolution to assist ease of use).
>
> Best,
> Ade.
>
>
> On 10/01/2011 21:46, Charles Moulliard wrote:
>
>> Hi,
>>
>> I would like to know if we have a property that we can setup to
>> register additional jar librairies (defined in a client folder
>> directory) like we do for JRE runtime libraries and expose them as
>> packages ? If this is not the case, could the hot "deploy" folder be
>> the alternative ?
>>
>> Regards,
>>
>> Charles Moulliard
>>
>> Sr. Principal Solution Architect - FuseSource
>> Apache Committer
>>
>> Blog : http://cmoulliard.blogspot.com
>> Twitter : http://twitter.com/cmoulliard
>> Linkedin : http://www.linkedin.com/in/charlesmoulliard
>> Skype: cmoulliard
>>
>
> --
> Adrian Trenaman, Sr. Principal Solution Architect
> FuseSource
> Phone: +353-86-6051026
> Email: trenaman@fusesource.com
> Web: http://trenaman.blogspot.com, http://fusesource.com
> Twitter: adrian_trenaman
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Register customer librairies like we do for JRE lib
Posted by "Moulliard, Charles" <cm...@fusesource.com>.
My concern is to deploy clients JARs like by example JARS used by project
Apache Hadoop
2011/1/11 Adrian Trenaman <tr...@progress.com>
> I *think* Charles's original suggestion was concerning client JARs, rather
> than bundles?
>
> @Charles: can you clarify?
>
>
> On 11/01/2011 09:58, Łukasz Dywicki wrote:
>
>> You may specify additional "repository" for Karaf. You may do that by
>> "bundle.locations" property in config.properties.
>>
>> Best regards,
>> Lukasz
>>
>> -----Original Message-----
>> From: Adrian Trenaman [mailto:trenaman@progress.com]
>> Sent: Tuesday, January 11, 2011 10:52 AM
>> To: dev@karaf.apache.org
>> Subject: Re: Register customer librairies like we do for JRE lib
>>
>> Hmmm.
>>
>> I think I recall Guillaume saying that you could achieve this by just
>> dropping them into a lib/ext directory?
>>
>> However, I prefer the idea of a 'Jar' deployer: if you drop a plain JAR
>> into the deploy directory, then it should depoy using wrap (and making
>> all dependencies marked for optional resolution to assist ease of use).
>>
>> Best,
>> Ade.
>>
>> On 10/01/2011 21:46, Charles Moulliard wrote:
>>
>>> Hi,
>>>
>>> I would like to know if we have a property that we can setup to
>>> register additional jar librairies (defined in a client folder
>>> directory) like we do for JRE runtime libraries and expose them as
>>> packages ? If this is not the case, could the hot "deploy" folder be
>>> the alternative ?
>>>
>>> Regards,
>>>
>>> Charles Moulliard
>>>
>>> Sr. Principal Solution Architect - FuseSource
>>> Apache Committer
>>>
>>> Blog : http://cmoulliard.blogspot.com
>>> Twitter : http://twitter.com/cmoulliard
>>> Linkedin : http://www.linkedin.com/in/charlesmoulliard
>>> Skype: cmoulliard
>>>
>>
> --
> Adrian Trenaman, Sr. Principal Solution Architect
> FuseSource
> Phone: +353-86-6051026
> Email: trenaman@fusesource.com
> Web: http://trenaman.blogspot.com, http://fusesource.com
> Twitter: adrian_trenaman
>
>
Re: Register customer librairies like we do for JRE lib
Posted by Adrian Trenaman <tr...@progress.com>.
I *think* Charles's original suggestion was concerning client JARs,
rather than bundles?
@Charles: can you clarify?
On 11/01/2011 09:58, Łukasz Dywicki wrote:
> You may specify additional "repository" for Karaf. You may do that by
> "bundle.locations" property in config.properties.
>
> Best regards,
> Lukasz
>
> -----Original Message-----
> From: Adrian Trenaman [mailto:trenaman@progress.com]
> Sent: Tuesday, January 11, 2011 10:52 AM
> To: dev@karaf.apache.org
> Subject: Re: Register customer librairies like we do for JRE lib
>
> Hmmm.
>
> I think I recall Guillaume saying that you could achieve this by just
> dropping them into a lib/ext directory?
>
> However, I prefer the idea of a 'Jar' deployer: if you drop a plain JAR
> into the deploy directory, then it should depoy using wrap (and making
> all dependencies marked for optional resolution to assist ease of use).
>
> Best,
> Ade.
>
> On 10/01/2011 21:46, Charles Moulliard wrote:
>> Hi,
>>
>> I would like to know if we have a property that we can setup to
>> register additional jar librairies (defined in a client folder
>> directory) like we do for JRE runtime libraries and expose them as
>> packages ? If this is not the case, could the hot "deploy" folder be
>> the alternative ?
>>
>> Regards,
>>
>> Charles Moulliard
>>
>> Sr. Principal Solution Architect - FuseSource
>> Apache Committer
>>
>> Blog : http://cmoulliard.blogspot.com
>> Twitter : http://twitter.com/cmoulliard
>> Linkedin : http://www.linkedin.com/in/charlesmoulliard
>> Skype: cmoulliard
--
Adrian Trenaman, Sr. Principal Solution Architect
FuseSource
Phone: +353-86-6051026
Email: trenaman@fusesource.com
Web: http://trenaman.blogspot.com, http://fusesource.com
Twitter: adrian_trenaman
RE: Register customer librairies like we do for JRE lib
Posted by Łukasz Dywicki <lu...@code-house.org>.
You may specify additional "repository" for Karaf. You may do that by
"bundle.locations" property in config.properties.
Best regards,
Lukasz
-----Original Message-----
From: Adrian Trenaman [mailto:trenaman@progress.com]
Sent: Tuesday, January 11, 2011 10:52 AM
To: dev@karaf.apache.org
Subject: Re: Register customer librairies like we do for JRE lib
Hmmm.
I think I recall Guillaume saying that you could achieve this by just
dropping them into a lib/ext directory?
However, I prefer the idea of a 'Jar' deployer: if you drop a plain JAR
into the deploy directory, then it should depoy using wrap (and making
all dependencies marked for optional resolution to assist ease of use).
Best,
Ade.
On 10/01/2011 21:46, Charles Moulliard wrote:
> Hi,
>
> I would like to know if we have a property that we can setup to
> register additional jar librairies (defined in a client folder
> directory) like we do for JRE runtime libraries and expose them as
> packages ? If this is not the case, could the hot "deploy" folder be
> the alternative ?
>
> Regards,
>
> Charles Moulliard
>
> Sr. Principal Solution Architect - FuseSource
> Apache Committer
>
> Blog : http://cmoulliard.blogspot.com
> Twitter : http://twitter.com/cmoulliard
> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> Skype: cmoulliard
--
Adrian Trenaman, Sr. Principal Solution Architect
FuseSource
Phone: +353-86-6051026
Email: trenaman@fusesource.com
Web: http://trenaman.blogspot.com, http://fusesource.com
Twitter: adrian_trenaman
Re: Register customer librairies like we do for JRE lib
Posted by Adrian Trenaman <tr...@progress.com>.
Hmmm.
I think I recall Guillaume saying that you could achieve this by just
dropping them into a lib/ext directory?
However, I prefer the idea of a 'Jar' deployer: if you drop a plain JAR
into the deploy directory, then it should depoy using wrap (and making
all dependencies marked for optional resolution to assist ease of use).
Best,
Ade.
On 10/01/2011 21:46, Charles Moulliard wrote:
> Hi,
>
> I would like to know if we have a property that we can setup to
> register additional jar librairies (defined in a client folder
> directory) like we do for JRE runtime libraries and expose them as
> packages ? If this is not the case, could the hot "deploy" folder be
> the alternative ?
>
> Regards,
>
> Charles Moulliard
>
> Sr. Principal Solution Architect - FuseSource
> Apache Committer
>
> Blog : http://cmoulliard.blogspot.com
> Twitter : http://twitter.com/cmoulliard
> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> Skype: cmoulliard
--
Adrian Trenaman, Sr. Principal Solution Architect
FuseSource
Phone: +353-86-6051026
Email: trenaman@fusesource.com
Web: http://trenaman.blogspot.com, http://fusesource.com
Twitter: adrian_trenaman