You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2011/01/20 15:07:10 UTC
New OSGi presentation
After some recent experiences I had with some developers trying to use
OSGi without even understanding the basics, I decided to work on a
presentation highlighting what you must understand about OSGi to use it.
Please find it on the presentations page:
http://felix.apache.org/site/presentations.html
The direct link to the PDF is here:
http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
Comments welcome.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: New OSGi presentation
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/20/11 9:47, Steven Siebert wrote:
> lol, nice cookie-jar references
>
> a couple comments....
>
> slides 15->19 was a bit confusing...you went from talking about OSGi
> modularity in 15 to the standard java packaging/classpath from 16-19
> without a visual transition. I found myself saying "wait...that's not
> right. If Rich says this, everything I know about life is wrong. Oh,
> wait...he wasn't talking OSGi, phew." Perhaps something on 17 that
> stated you were taking about java now, not continuing the thought on
> OSGi from 15 =)
Ok, I'll try to make that clearer.
> I think you hit on many good points, all critical to know when
> designing/developing an OSGi based application...but a co-worker (who
> does not know OSGi) heard me chuckle at cookie monster and said "124
> slides as an intro/how to ignore OSGi?"....I understand most were
> inner-slide transitions, but was a comment that was made =)
Yeah, I understand that people will have that reaction. I always do my
animations as slide transitions, so people can easily watch them from
PDF. The number of slides is actually much less. I guess it could put
someone off if they just look at that number and stop immediately...but
hopefully they won't do that. :-)
> all together, though, a good presentation. I'll add this to the docs
> I'm going to use to teach my co-workers OSGi.
Thanks.
-> richard
> Thanks,
>
> S
>
> On Thu, Jan 20, 2011 at 9:07 AM, Richard S. Hall<he...@ungoverned.org> wrote:
>> After some recent experiences I had with some developers trying to use OSGi
>> without even understanding the basics, I decided to work on a presentation
>> highlighting what you must understand about OSGi to use it. Please find it
>> on the presentations page:
>>
>> http://felix.apache.org/site/presentations.html
>>
>> The direct link to the PDF is here:
>>
>>
>> http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
>>
>> Comments welcome.
>>
>> -> richard
>>
>> ---------------------------------------------------------------------
>> 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
Re: New OSGi presentation
Posted by Steven Siebert <sm...@gmail.com>.
lol, nice cookie-jar references
a couple comments....
slides 15->19 was a bit confusing...you went from talking about OSGi
modularity in 15 to the standard java packaging/classpath from 16-19
without a visual transition. I found myself saying "wait...that's not
right. If Rich says this, everything I know about life is wrong. Oh,
wait...he wasn't talking OSGi, phew." Perhaps something on 17 that
stated you were taking about java now, not continuing the thought on
OSGi from 15 =)
I think you hit on many good points, all critical to know when
designing/developing an OSGi based application...but a co-worker (who
does not know OSGi) heard me chuckle at cookie monster and said "124
slides as an intro/how to ignore OSGi?"....I understand most were
inner-slide transitions, but was a comment that was made =)
all together, though, a good presentation. I'll add this to the docs
I'm going to use to teach my co-workers OSGi.
Thanks,
S
On Thu, Jan 20, 2011 at 9:07 AM, Richard S. Hall <he...@ungoverned.org> wrote:
> After some recent experiences I had with some developers trying to use OSGi
> without even understanding the basics, I decided to work on a presentation
> highlighting what you must understand about OSGi to use it. Please find it
> on the presentations page:
>
> http://felix.apache.org/site/presentations.html
>
> The direct link to the PDF is here:
>
>
> http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
>
> Comments welcome.
>
> -> richard
>
> ---------------------------------------------------------------------
> 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
Re: New OSGi presentation
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/20/11 6:46 PM, Per-Erik Svensson wrote:
> Agreed it's not a completely fair comparison. And point taken. Maybe it's a
> tooling problem though. Most IDEs abstract away the classpath and the only
> time you deal with it is when deploying desktop apps (?). And I wasn't
> talking about the presentation specifically but OSGi in general. You do have
> to understand alot more about class loading than I would like to believe is
> necessary. At least if one want to be able to parse the error messages. But
> maybe I'm wrong, maybe it is necessary to know that there is a class loading
> search policy and what boot delegation means. I will continue to live with
> the hope that future OSGi specifications/implementations will abstract away
> more of this though, but maybe it's hard or even impossible! :) (Thinking
> about it, maybe I'm just biased because I'm so used to the classpath... Just
> like I hope to becoming used to OSGi and "no longer have to care about it".)
To parse the error messages you need to know something about how OSGi
resolves dependencies and the search order it uses to find types, but I
think that's it. In theory, you shouldn't even have to understand boot
delegation (except for java.* packages). So, I think your view is about
right.
> And it does so good. I didn't mean to imply otherwise. I just saw what I
> believed to be a few to many classloading troubleshooting pages that could
> be swapped out with services. But you're probably right. You have a good
> focus on modularity now instead.
Oh, is that what you meant. Yeah, you are correct, I could probably add
a bullet in the class loading slides at the end saying "Maybe you should
investigate services"...
-> richard
> On Fri, Jan 21, 2011 at 12:01 AM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>> On 1/20/11 17:13, Per-Erik Svensson wrote:
>>
>>> Great read, although a little "hostile" to newcomers maybe. :)
>>>
>> I guess you could interpret it that way, but that wasn't the intent. Maybe
>> hostile to people who think they can use something without even attempting
>> to understand it, but really i was just trying to make assumptions clear.
>>
>>
>> The parts about class loading might, as others have suggested, be a bit
>>> too
>>> complex for us average java developers too. I certainly didn't know about
>>> this before starting with OSGi. And I still have alot to learn of course!
>>> And I believe this is the place where OSGi has the most left to do. Class
>>> loading is an implementation detail that shines through. When I declare a
>>> method to be private, I never have to worry about how the JVM enforces
>>> that.
>>> In the same sense, I shouldn't have to worry about how OSGi enforces
>>> package
>>> visibility. But that's another story.
>>>
>> Technically, the presentation is about type visibility, not class loading.
>> Only at the end do I talk about class loading...and definitely the end is a
>> little more complicated. However, type visibility shines through even in
>> standard Java...if you don't understand how to set the CLASSPATH variable,
>> you don't get very far in Java. So, the main point is that the "standard"
>> type visibility rules no longer apply in OSGi, you must learn new type
>> visibility rules.
>>
>> So, in that regard, I don't agree with your implication that you need to
>> worry about how OSGi enforces visibility, since I don't really talk about
>> class loaders at all. In the end, you need to understand what the primitives
>> mean and what to do when you get an error. Just like if you make a method
>> package private and try to access it from another package...you have to
>> understand that this is an error and how to fix it. Module visibility is
>> exactly the same (if you don't specify a type as "module public" (i.e.,
>> export it) and then try to access it from another module you'll get an
>> error...no need to understand anything about class loaders...but for
>> debugging it can help to understand search order, just like the class path).
>>
>>
>> Also, I think a presentation like this is a great place to emphasize the
>>> difference between "jar dependency management" and "package dependeny
>>> management". Had I read the presentation a few years back (two maybe)
>>> before
>>> having started to "Felix" (yes, it's a verb now), I might have thought
>>> "Well, maven does most of this for me, and without those silly
>>> restrictions!.". It is a profound point about OSGi that might be easily
>>> missed when reading "starter materail". But I guess one can't cover
>>> everything at every possible depth. And you do talk about it, and you do
>>> mention versions. I just think that the whole "per package!!" idea might
>>> get
>>> lost between all modules, jars and cookies. :) A module is a set of
>>> packages, depending on other modules with packages. A module is not a jar
>>> with classes depending on other jars with classes (as with maven).
>>>
>> I agree that this is a distinction, but it is between Maven and OSGi. This
>> presentation highlights the differences between standard Java and OSGi. In
>> standard Java there is no concept of a dependency at all. Perhaps there
>> could be a footnote in there for all the Maven users. :-)
>>
>>
>> And of course, to further shoot down "maven does it for me"-like
>>> arguments,
>>> slam a big "services means *modularized* *dynamism*" sticker on top of
>>> every
>>> page. Ok, don't... But, as I said, people might get the impression that
>>> OSGi
>>> is a way to manage your jars - when it can actually cook and wash your car
>>> too.
>>>
>> Yeah, this presentation focuses on the minimum...in particular, it focuses
>> purely on modularity since that is often the entry point for people and they
>> only get that far.
>>
>>
>> As said, very interesting read! In fact, it got me wondering about a few
>>> things so I'm off asking questions in a mail list near you! Thanks! :)
>>>
>> Thanks for the feedback.
>>
>> -> richard
>>
>>
>> Regards,
>>> Per-Erik Svensson
>>>
>>>
>>> On Thu, Jan 20, 2011 at 5:32 PM, Richard S. Hall<heavy@ungoverned.org
>>>> wrote:
>>> On 1/20/11 10:47, john.dunlap@exceter.com wrote:
>>>> Thanks for doing this Richard!
>>>>> I like the sound of OSGi but I've never made the leap to it because I
>>>>> don't feel that I understand it well enough to convince myself that it
>>>>> is
>>>>> the right direction to go in.
>>>>>
>>>>> Your slides have clarified a number of things for me and your analogies
>>>>> are both clever and funny! I found the slides very easy to follow but I
>>>>> found myself getting confused in the "Understanding search order" and
>>>>> "When
>>>>> things go wrong..." sections, I think partially because I don't have a
>>>>> solid
>>>>> grasp of the terminology. What is class loader delegation?
>>>>>
>>>>> I am familiar with the notion of dependency management from my
>>>>> experiences
>>>>> with using Maven to build my projects so I can somewhat follow you in
>>>>> the
>>>>> "When things go wrong..." section where you first mention transitive
>>>>> dependencies. However, old school developers that are stuck using Ant
>>>>> might
>>>>> find it more difficult. You touch on the subject in various places but I
>>>>> think it would be helpful if you had a couple of slides that briefly
>>>>> talked
>>>>> about dependency management in the context of OSGi before moving on to
>>>>> troubleshooting.
>>>>>
>>>>> Those two sections will be the most difficult to follow, for sure, so
>>>> you'll just have to catch me presenting it sometime. :-)
>>>>
>>>> Seriously, though, I am already working on improving that section by
>>>> trying
>>>> to improve the error messages printed by the Felix framework. I will see
>>>> if
>>>> there is anything else I can do to add some more introductory overview
>>>> for
>>>> class loaders (without adding too many more slides).
>>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>> Cheers!
>>>>> -John
>>>>>
>>>>> Quoting "Richard S. Hall"<he...@ungoverned.org>:
>>>>>
>>>>> After some recent experiences I had with some developers trying to use
>>>>>
>>>>>> OSGi without even understanding the basics, I decided to work on a
>>>>>> presentation highlighting what you must understand about OSGi to use
>>>>>> it. Please find it on the presentations page:
>>>>>>
>>>>>> http://felix.apache.org/site/presentations.html
>>>>>>
>>>>>> The direct link to the PDF is here:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
>>>>>>
>>>>>> Comments welcome.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
Re: New OSGi presentation
Posted by Per-Erik Svensson <pe...@gmail.com>.
"I guess you could interpret it that way, but that wasn't the intent."
I understand that and I didn't take it as hostile. But I couldn't find a
better word, although I'm sure there are plenty. :)
"However, type visibility shines through even in standard Java...if you
don't understand how to set the CLASSPATH variable, you don't get very far
in Java."
Agreed it's not a completely fair comparison. And point taken. Maybe it's a
tooling problem though. Most IDEs abstract away the classpath and the only
time you deal with it is when deploying desktop apps (?). And I wasn't
talking about the presentation specifically but OSGi in general. You do have
to understand alot more about class loading than I would like to believe is
necessary. At least if one want to be able to parse the error messages. But
maybe I'm wrong, maybe it is necessary to know that there is a class loading
search policy and what boot delegation means. I will continue to live with
the hope that future OSGi specifications/implementations will abstract away
more of this though, but maybe it's hard or even impossible! :) (Thinking
about it, maybe I'm just biased because I'm so used to the classpath... Just
like I hope to becoming used to OSGi and "no longer have to care about it".)
"Perhaps there could be a footnote in there for all the Maven users."
Hehe, no, no, that's working in the wrong direction. Maven should come with
a footnote about OSGi!! :)
"Yeah, this presentation focuses on the minimum..."
And it does so good. I didn't mean to imply otherwise. I just saw what I
believed to be a few to many classloading troubleshooting pages that could
be swapped out with services. But you're probably right. You have a good
focus on modularity now instead.
Regards,
Per-Erik Svensson
On Fri, Jan 21, 2011 at 12:01 AM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 1/20/11 17:13, Per-Erik Svensson wrote:
>
>> Great read, although a little "hostile" to newcomers maybe. :)
>>
>
> I guess you could interpret it that way, but that wasn't the intent. Maybe
> hostile to people who think they can use something without even attempting
> to understand it, but really i was just trying to make assumptions clear.
>
>
> The parts about class loading might, as others have suggested, be a bit
>> too
>> complex for us average java developers too. I certainly didn't know about
>> this before starting with OSGi. And I still have alot to learn of course!
>> And I believe this is the place where OSGi has the most left to do. Class
>> loading is an implementation detail that shines through. When I declare a
>> method to be private, I never have to worry about how the JVM enforces
>> that.
>> In the same sense, I shouldn't have to worry about how OSGi enforces
>> package
>> visibility. But that's another story.
>>
>
> Technically, the presentation is about type visibility, not class loading.
> Only at the end do I talk about class loading...and definitely the end is a
> little more complicated. However, type visibility shines through even in
> standard Java...if you don't understand how to set the CLASSPATH variable,
> you don't get very far in Java. So, the main point is that the "standard"
> type visibility rules no longer apply in OSGi, you must learn new type
> visibility rules.
>
> So, in that regard, I don't agree with your implication that you need to
> worry about how OSGi enforces visibility, since I don't really talk about
> class loaders at all. In the end, you need to understand what the primitives
> mean and what to do when you get an error. Just like if you make a method
> package private and try to access it from another package...you have to
> understand that this is an error and how to fix it. Module visibility is
> exactly the same (if you don't specify a type as "module public" (i.e.,
> export it) and then try to access it from another module you'll get an
> error...no need to understand anything about class loaders...but for
> debugging it can help to understand search order, just like the class path).
>
>
> Also, I think a presentation like this is a great place to emphasize the
>> difference between "jar dependency management" and "package dependeny
>> management". Had I read the presentation a few years back (two maybe)
>> before
>> having started to "Felix" (yes, it's a verb now), I might have thought
>> "Well, maven does most of this for me, and without those silly
>> restrictions!.". It is a profound point about OSGi that might be easily
>> missed when reading "starter materail". But I guess one can't cover
>> everything at every possible depth. And you do talk about it, and you do
>> mention versions. I just think that the whole "per package!!" idea might
>> get
>> lost between all modules, jars and cookies. :) A module is a set of
>> packages, depending on other modules with packages. A module is not a jar
>> with classes depending on other jars with classes (as with maven).
>>
>
> I agree that this is a distinction, but it is between Maven and OSGi. This
> presentation highlights the differences between standard Java and OSGi. In
> standard Java there is no concept of a dependency at all. Perhaps there
> could be a footnote in there for all the Maven users. :-)
>
>
> And of course, to further shoot down "maven does it for me"-like
>> arguments,
>> slam a big "services means *modularized* *dynamism*" sticker on top of
>> every
>> page. Ok, don't... But, as I said, people might get the impression that
>> OSGi
>> is a way to manage your jars - when it can actually cook and wash your car
>> too.
>>
>
> Yeah, this presentation focuses on the minimum...in particular, it focuses
> purely on modularity since that is often the entry point for people and they
> only get that far.
>
>
> As said, very interesting read! In fact, it got me wondering about a few
>> things so I'm off asking questions in a mail list near you! Thanks! :)
>>
>
> Thanks for the feedback.
>
> -> richard
>
>
> Regards,
>> Per-Erik Svensson
>>
>>
>> On Thu, Jan 20, 2011 at 5:32 PM, Richard S. Hall<heavy@ungoverned.org
>> >wrote:
>>
>> On 1/20/11 10:47, john.dunlap@exceter.com wrote:
>>>
>>> Thanks for doing this Richard!
>>>>
>>>> I like the sound of OSGi but I've never made the leap to it because I
>>>> don't feel that I understand it well enough to convince myself that it
>>>> is
>>>> the right direction to go in.
>>>>
>>>> Your slides have clarified a number of things for me and your analogies
>>>> are both clever and funny! I found the slides very easy to follow but I
>>>> found myself getting confused in the "Understanding search order" and
>>>> "When
>>>> things go wrong..." sections, I think partially because I don't have a
>>>> solid
>>>> grasp of the terminology. What is class loader delegation?
>>>>
>>>> I am familiar with the notion of dependency management from my
>>>> experiences
>>>> with using Maven to build my projects so I can somewhat follow you in
>>>> the
>>>> "When things go wrong..." section where you first mention transitive
>>>> dependencies. However, old school developers that are stuck using Ant
>>>> might
>>>> find it more difficult. You touch on the subject in various places but I
>>>> think it would be helpful if you had a couple of slides that briefly
>>>> talked
>>>> about dependency management in the context of OSGi before moving on to
>>>> troubleshooting.
>>>>
>>>> Those two sections will be the most difficult to follow, for sure, so
>>> you'll just have to catch me presenting it sometime. :-)
>>>
>>> Seriously, though, I am already working on improving that section by
>>> trying
>>> to improve the error messages printed by the Felix framework. I will see
>>> if
>>> there is anything else I can do to add some more introductory overview
>>> for
>>> class loaders (without adding too many more slides).
>>>
>>> -> richard
>>>
>>>
>>>
>>> Cheers!
>>>> -John
>>>>
>>>> Quoting "Richard S. Hall"<he...@ungoverned.org>:
>>>>
>>>> After some recent experiences I had with some developers trying to use
>>>>
>>>>> OSGi without even understanding the basics, I decided to work on a
>>>>> presentation highlighting what you must understand about OSGi to use
>>>>> it. Please find it on the presentations page:
>>>>>
>>>>> http://felix.apache.org/site/presentations.html
>>>>>
>>>>> The direct link to the PDF is here:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
>>>>>
>>>>> Comments welcome.
>>>>>
>>>>> -> richard
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>
>
Re: New OSGi presentation
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/20/11 17:13, Per-Erik Svensson wrote:
> Great read, although a little "hostile" to newcomers maybe. :)
I guess you could interpret it that way, but that wasn't the intent.
Maybe hostile to people who think they can use something without even
attempting to understand it, but really i was just trying to make
assumptions clear.
> The parts about class loading might, as others have suggested, be a bit too
> complex for us average java developers too. I certainly didn't know about
> this before starting with OSGi. And I still have alot to learn of course!
> And I believe this is the place where OSGi has the most left to do. Class
> loading is an implementation detail that shines through. When I declare a
> method to be private, I never have to worry about how the JVM enforces that.
> In the same sense, I shouldn't have to worry about how OSGi enforces package
> visibility. But that's another story.
Technically, the presentation is about type visibility, not class
loading. Only at the end do I talk about class loading...and definitely
the end is a little more complicated. However, type visibility shines
through even in standard Java...if you don't understand how to set the
CLASSPATH variable, you don't get very far in Java. So, the main point
is that the "standard" type visibility rules no longer apply in OSGi,
you must learn new type visibility rules.
So, in that regard, I don't agree with your implication that you need to
worry about how OSGi enforces visibility, since I don't really talk
about class loaders at all. In the end, you need to understand what the
primitives mean and what to do when you get an error. Just like if you
make a method package private and try to access it from another
package...you have to understand that this is an error and how to fix
it. Module visibility is exactly the same (if you don't specify a type
as "module public" (i.e., export it) and then try to access it from
another module you'll get an error...no need to understand anything
about class loaders...but for debugging it can help to understand search
order, just like the class path).
> Also, I think a presentation like this is a great place to emphasize the
> difference between "jar dependency management" and "package dependeny
> management". Had I read the presentation a few years back (two maybe) before
> having started to "Felix" (yes, it's a verb now), I might have thought
> "Well, maven does most of this for me, and without those silly
> restrictions!.". It is a profound point about OSGi that might be easily
> missed when reading "starter materail". But I guess one can't cover
> everything at every possible depth. And you do talk about it, and you do
> mention versions. I just think that the whole "per package!!" idea might get
> lost between all modules, jars and cookies. :) A module is a set of
> packages, depending on other modules with packages. A module is not a jar
> with classes depending on other jars with classes (as with maven).
I agree that this is a distinction, but it is between Maven and OSGi.
This presentation highlights the differences between standard Java and
OSGi. In standard Java there is no concept of a dependency at all.
Perhaps there could be a footnote in there for all the Maven users. :-)
> And of course, to further shoot down "maven does it for me"-like arguments,
> slam a big "services means *modularized* *dynamism*" sticker on top of every
> page. Ok, don't... But, as I said, people might get the impression that OSGi
> is a way to manage your jars - when it can actually cook and wash your car
> too.
Yeah, this presentation focuses on the minimum...in particular, it
focuses purely on modularity since that is often the entry point for
people and they only get that far.
> As said, very interesting read! In fact, it got me wondering about a few
> things so I'm off asking questions in a mail list near you! Thanks! :)
Thanks for the feedback.
-> richard
> Regards,
> Per-Erik Svensson
>
>
> On Thu, Jan 20, 2011 at 5:32 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>> On 1/20/11 10:47, john.dunlap@exceter.com wrote:
>>
>>> Thanks for doing this Richard!
>>>
>>> I like the sound of OSGi but I've never made the leap to it because I
>>> don't feel that I understand it well enough to convince myself that it is
>>> the right direction to go in.
>>>
>>> Your slides have clarified a number of things for me and your analogies
>>> are both clever and funny! I found the slides very easy to follow but I
>>> found myself getting confused in the "Understanding search order" and "When
>>> things go wrong..." sections, I think partially because I don't have a solid
>>> grasp of the terminology. What is class loader delegation?
>>>
>>> I am familiar with the notion of dependency management from my experiences
>>> with using Maven to build my projects so I can somewhat follow you in the
>>> "When things go wrong..." section where you first mention transitive
>>> dependencies. However, old school developers that are stuck using Ant might
>>> find it more difficult. You touch on the subject in various places but I
>>> think it would be helpful if you had a couple of slides that briefly talked
>>> about dependency management in the context of OSGi before moving on to
>>> troubleshooting.
>>>
>> Those two sections will be the most difficult to follow, for sure, so
>> you'll just have to catch me presenting it sometime. :-)
>>
>> Seriously, though, I am already working on improving that section by trying
>> to improve the error messages printed by the Felix framework. I will see if
>> there is anything else I can do to add some more introductory overview for
>> class loaders (without adding too many more slides).
>>
>> -> richard
>>
>>
>>
>>> Cheers!
>>> -John
>>>
>>> Quoting "Richard S. Hall"<he...@ungoverned.org>:
>>>
>>> After some recent experiences I had with some developers trying to use
>>>> OSGi without even understanding the basics, I decided to work on a
>>>> presentation highlighting what you must understand about OSGi to use
>>>> it. Please find it on the presentations page:
>>>>
>>>> http://felix.apache.org/site/presentations.html
>>>>
>>>> The direct link to the PDF is here:
>>>>
>>>>
>>>>
>>>> http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
>>>>
>>>> Comments welcome.
>>>>
>>>> -> richard
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
Re: New OSGi presentation
Posted by Per-Erik Svensson <pe...@gmail.com>.
Great read, although a little "hostile" to newcomers maybe. :)
The parts about class loading might, as others have suggested, be a bit too
complex for us average java developers too. I certainly didn't know about
this before starting with OSGi. And I still have alot to learn of course!
And I believe this is the place where OSGi has the most left to do. Class
loading is an implementation detail that shines through. When I declare a
method to be private, I never have to worry about how the JVM enforces that.
In the same sense, I shouldn't have to worry about how OSGi enforces package
visibility. But that's another story.
Also, I think a presentation like this is a great place to emphasize the
difference between "jar dependency management" and "package dependeny
management". Had I read the presentation a few years back (two maybe) before
having started to "Felix" (yes, it's a verb now), I might have thought
"Well, maven does most of this for me, and without those silly
restrictions!.". It is a profound point about OSGi that might be easily
missed when reading "starter materail". But I guess one can't cover
everything at every possible depth. And you do talk about it, and you do
mention versions. I just think that the whole "per package!!" idea might get
lost between all modules, jars and cookies. :) A module is a set of
packages, depending on other modules with packages. A module is not a jar
with classes depending on other jars with classes (as with maven).
And of course, to further shoot down "maven does it for me"-like arguments,
slam a big "services means *modularized* *dynamism*" sticker on top of every
page. Ok, don't... But, as I said, people might get the impression that OSGi
is a way to manage your jars - when it can actually cook and wash your car
too.
As said, very interesting read! In fact, it got me wondering about a few
things so I'm off asking questions in a mail list near you! Thanks! :)
Regards,
Per-Erik Svensson
On Thu, Jan 20, 2011 at 5:32 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
> On 1/20/11 10:47, john.dunlap@exceter.com wrote:
>
>> Thanks for doing this Richard!
>>
>> I like the sound of OSGi but I've never made the leap to it because I
>> don't feel that I understand it well enough to convince myself that it is
>> the right direction to go in.
>>
>> Your slides have clarified a number of things for me and your analogies
>> are both clever and funny! I found the slides very easy to follow but I
>> found myself getting confused in the "Understanding search order" and "When
>> things go wrong..." sections, I think partially because I don't have a solid
>> grasp of the terminology. What is class loader delegation?
>>
>> I am familiar with the notion of dependency management from my experiences
>> with using Maven to build my projects so I can somewhat follow you in the
>> "When things go wrong..." section where you first mention transitive
>> dependencies. However, old school developers that are stuck using Ant might
>> find it more difficult. You touch on the subject in various places but I
>> think it would be helpful if you had a couple of slides that briefly talked
>> about dependency management in the context of OSGi before moving on to
>> troubleshooting.
>>
>
> Those two sections will be the most difficult to follow, for sure, so
> you'll just have to catch me presenting it sometime. :-)
>
> Seriously, though, I am already working on improving that section by trying
> to improve the error messages printed by the Felix framework. I will see if
> there is anything else I can do to add some more introductory overview for
> class loaders (without adding too many more slides).
>
> -> richard
>
>
>
>> Cheers!
>> -John
>>
>> Quoting "Richard S. Hall" <he...@ungoverned.org>:
>>
>> After some recent experiences I had with some developers trying to use
>>> OSGi without even understanding the basics, I decided to work on a
>>> presentation highlighting what you must understand about OSGi to use
>>> it. Please find it on the presentations page:
>>>
>>> http://felix.apache.org/site/presentations.html
>>>
>>> The direct link to the PDF is here:
>>>
>>>
>>>
>>> http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
>>>
>>> Comments welcome.
>>>
>>> -> richard
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
Re: New OSGi presentation
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/20/11 10:47, john.dunlap@exceter.com wrote:
> Thanks for doing this Richard!
>
> I like the sound of OSGi but I've never made the leap to it because I
> don't feel that I understand it well enough to convince myself that it
> is the right direction to go in.
>
> Your slides have clarified a number of things for me and your
> analogies are both clever and funny! I found the slides very easy to
> follow but I found myself getting confused in the "Understanding
> search order" and "When things go wrong..." sections, I think
> partially because I don't have a solid grasp of the terminology. What
> is class loader delegation?
>
> I am familiar with the notion of dependency management from my
> experiences with using Maven to build my projects so I can somewhat
> follow you in the "When things go wrong..." section where you first
> mention transitive dependencies. However, old school developers that
> are stuck using Ant might find it more difficult. You touch on the
> subject in various places but I think it would be helpful if you had a
> couple of slides that briefly talked about dependency management in
> the context of OSGi before moving on to troubleshooting.
Those two sections will be the most difficult to follow, for sure, so
you'll just have to catch me presenting it sometime. :-)
Seriously, though, I am already working on improving that section by
trying to improve the error messages printed by the Felix framework. I
will see if there is anything else I can do to add some more
introductory overview for class loaders (without adding too many more
slides).
-> richard
>
> Cheers!
> -John
>
> Quoting "Richard S. Hall" <he...@ungoverned.org>:
>
>> After some recent experiences I had with some developers trying to use
>> OSGi without even understanding the basics, I decided to work on a
>> presentation highlighting what you must understand about OSGi to use
>> it. Please find it on the presentations page:
>>
>> http://felix.apache.org/site/presentations.html
>>
>> The direct link to the PDF is here:
>>
>>
>> http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
>>
>>
>> Comments welcome.
>>
>> -> richard
>>
>> ---------------------------------------------------------------------
>> 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
Re: New OSGi presentation
Posted by jo...@exceter.com.
Thanks for doing this Richard!
I like the sound of OSGi but I've never made the leap to it because I
don't feel that I understand it well enough to convince myself that it
is the right direction to go in.
Your slides have clarified a number of things for me and your
analogies are both clever and funny! I found the slides very easy to
follow but I found myself getting confused in the "Understanding
search order" and "When things go wrong..." sections, I think
partially because I don't have a solid grasp of the terminology. What
is class loader delegation?
I am familiar with the notion of dependency management from my
experiences with using Maven to build my projects so I can somewhat
follow you in the "When things go wrong..." section where you first
mention transitive dependencies. However, old school developers that
are stuck using Ant might find it more difficult. You touch on the
subject in various places but I think it would be helpful if you had a
couple of slides that briefly talked about dependency management in
the context of OSGi before moving on to troubleshooting.
Cheers!
-John
Quoting "Richard S. Hall" <he...@ungoverned.org>:
> After some recent experiences I had with some developers trying to use
> OSGi without even understanding the basics, I decided to work on a
> presentation highlighting what you must understand about OSGi to use
> it. Please find it on the presentations page:
>
> http://felix.apache.org/site/presentations.html
>
> The direct link to the PDF is here:
>
>
> http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
>
> Comments welcome.
>
> -> richard
>
> ---------------------------------------------------------------------
> 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
Re: New OSGi presentation
Posted by Rob Walker <ro...@ascert.com>.
Also thanks from our side Richard (and a belated congrats on your 2nd
child).
We occasionally have new developers working with us, so it's useful to
have something to orient them to OSGi.
I've lost count of how many times I've had to explain that you can't
rely on a static being a globally accessible singleton in an OSGi
environment, because statics are only global per classloader ...
- Rob
On 24/01/2011 9:44 PM, Felix Meschberger wrote:
> Hi,
>
> Not very constructive, but still: Thank you very much !
>
> Regards
> Felix
>
> Am Donnerstag, den 20.01.2011, 14:07 +0000 schrieb Richard S. Hall:
>> After some recent experiences I had with some developers trying to use
>> OSGi without even understanding the basics, I decided to work on a
>> presentation highlighting what you must understand about OSGi to use it.
>> Please find it on the presentations page:
>>
>> http://felix.apache.org/site/presentations.html
>>
>> The direct link to the PDF is here:
>>
>>
>> http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
>>
>> Comments welcome.
>>
>> -> richard
>>
>> ---------------------------------------------------------------------
>> 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
>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: New OSGi presentation
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Not very constructive, but still: Thank you very much !
Regards
Felix
Am Donnerstag, den 20.01.2011, 14:07 +0000 schrieb Richard S. Hall:
> After some recent experiences I had with some developers trying to use
> OSGi without even understanding the basics, I decided to work on a
> presentation highlighting what you must understand about OSGi to use it.
> Please find it on the presentations page:
>
> http://felix.apache.org/site/presentations.html
>
> The direct link to the PDF is here:
>
>
> http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
>
> Comments welcome.
>
> -> richard
>
> ---------------------------------------------------------------------
> 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
Re: New OSGi presentation
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/20/11 10:18, Rémon. Sinnema wrote:
>
> ----- Original Message ----
>
> From: Richard S. Hall<he...@ungoverned.org>
> To: users@felix.apache.org
> Sent: Thu, January 20, 2011 3:07:10 PM
> Subject: New OSGi presentation
>
>> Comments welcome.
> Slide 5: "I've never ready any OSGi documentation at all."
> ready => read
Surprised I missed that after so many reads...I've uploaded a new
version which should propagate before too long.
Thanks.
-> richard
>
>
>
> ---------------------------------------------------------------------
> 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
Re: New OSGi presentation
Posted by "Rémon. Sinnema" <rs...@yahoo.com>.
----- Original Message ----
From: Richard S. Hall <he...@ungoverned.org>
To: users@felix.apache.org
Sent: Thu, January 20, 2011 3:07:10 PM
Subject: New OSGi presentation
> Comments welcome.
Slide 5: "I've never ready any OSGi documentation at all."
ready => read
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix - File Install
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/2/11 10:36, Muller, Anthony wrote:
> Hello,
>
> I'm trying to use FileInstall but it doesn't work :-/
>
> I wrote an eclipse project with an only dependency with Felix.
>
> I put "org.apache.felix.fileinstall-3.1.4.jar" in a "bundles" directory and this one is properly deploy by Felix.
>
> But I cannot configure FileInstall to manage a "dropins" directory in order to automatically start bundles present here.
>
> Thanks for help,
> Anthony
>
>
> public class FelixLauncher {
>
> private final HostActivator activator = new HostActivator();
>
> private Framework felix;
>
> public FelixLauncher() {
> // Create a configuration property map.
> final Map<Object, Object> configMap = new HashMap<Object, Object>();
>
> // Create host activator;
> final List<Object> list = new ArrayList<Object>();
> list.add(activator);
> configMap.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, list);
> configMap.put(AutoProcessor.AUTO_DEPLOY_DIR_PROPERY, "bundles");
> configMap.put(AutoProcessor.AUTO_DEPLOY_ACTION_PROPERY, AutoProcessor.AUTO_DEPLOY_INSTALL_VALUE);
You are only telling the auto-deploy mechanism to install bundles, you
want to set the value to "install, start" so that it installs and starts
the auto-deploy bundles.
-> richard
> try {
> felix = new Felix(configMap);
> felix.init();
>
> AutoProcessor.process(configMap, felix.getBundleContext());
>
> felix.start();
>
> Bundle[] bnds = felix.getBundleContext().getBundles();
> for (Bundle bundle : bnds) {
> bundle.start();
> System.out.println(bundle + " : " + bundle.getState());
> }
> } catch (Exception ex) {
> ex.printStackTrace();
> }
> }
>
> public Framework getFramework() {
> return felix;
> }
> }
>
> ---------------------------------------------------------------------
> 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
RE: Felix - File Install
Posted by "Muller, Anthony" <an...@sap.com>.
Thnks Richard & Guillaume, I read this webpage and I understand how to configure Felix and deployed bundles now:
http://felix.apache.org/site/apache-felix-framework-usage-documentation.html#ApacheFelixFrameworkUsageDocumentation-configuringframework
Regards,
Anthony
-----Original Message-----
From: Guillaume Nodet [mailto:gnodet@gmail.com]
Sent: mercredi 2 février 2011 18:03
To: users@felix.apache.org
Subject: Re: Felix - File Install
It should find the default values in the system proeprties or
framework properties, so if you append those at the end of the felix
configuration file, it should work.
On Wed, Feb 2, 2011 at 17:26, Richard S. Hall <he...@ungoverned.org> wrote:
> On 2/2/11 11:12, Muller, Anthony wrote:
>>
>> Richard,
>>
>> According your advice, I changed the auto-deploy value to "install,
>> start".
>>
>> So, when I print out bundles present in context, I have:
>> org.apache.felix.framework [0] : 32
>> org.apache.felix.fileinstall [1] : 32
>>
>> But, FileInstall is still not properly configured. Where must I put the
>> configuration file? Must I use a specific file name?
>
> I'll let the File Install experts answer that...
>
> -> richard
>
>> Thanks and regards,
>> Anthony
>>
>>
>>
>> "You are only telling the auto-deploy mechanism to install bundles, you
>> want to set the value to "install, start" so that it installs and starts the
>> auto-deploy bundles.
>> -> richard"
>>
>> -----Original Message-----
>> From: Muller, Anthony [mailto:anthony.muller@sap.com]
>> Sent: mercredi 2 février 2011 16:40
>> To: users@felix.apache.org
>> Subject: RE: Felix - File Install
>>
>> I forgot to say that I wrote a configuration file:
>>
>> [conf/config.properties]
>> felix.fileinstall.poll=12000
>> felix.fileinstall.dir=dropins
>> felix.fileinstall.debug=-1
>> felix.fileinstall.bundles.new.start=true
>>
>> But I don't know how FileInstall can be able to find this configuration
>> file... :(
>>
>> Anthony
>>
>>
>> -----Original Message-----
>> From: Muller, Anthony [mailto:anthony.muller@sap.com]
>> Sent: mercredi 2 février 2011 16:36
>> To: users@felix.apache.org
>> Subject: Felix - File Install
>>
>> Hello,
>>
>> I'm trying to use FileInstall but it doesn't work :-/
>>
>> I wrote an eclipse project with an only dependency with Felix.
>>
>> I put "org.apache.felix.fileinstall-3.1.4.jar" in a "bundles" directory
>> and this one is properly deploy by Felix.
>>
>> But I cannot configure FileInstall to manage a "dropins" directory in
>> order to automatically start bundles present here.
>>
>> Thanks for help,
>> Anthony
>>
>>
>> public class FelixLauncher {
>>
>> private final HostActivator activator = new HostActivator();
>>
>> private Framework felix;
>>
>> public FelixLauncher() {
>> // Create a configuration property map.
>> final Map<Object, Object> configMap = new HashMap<Object,
>> Object>();
>>
>> // Create host activator;
>> final List<Object> list = new ArrayList<Object>();
>> list.add(activator);
>> configMap.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
>> list);
>> configMap.put(AutoProcessor.AUTO_DEPLOY_DIR_PROPERY,
>> "bundles");
>> configMap.put(AutoProcessor.AUTO_DEPLOY_ACTION_PROPERY,
>> AutoProcessor.AUTO_DEPLOY_INSTALL_VALUE);
>>
>> try {
>> felix = new Felix(configMap);
>> felix.init();
>>
>> AutoProcessor.process(configMap,
>> felix.getBundleContext());
>>
>> felix.start();
>>
>> Bundle[] bnds =
>> felix.getBundleContext().getBundles();
>> for (Bundle bundle : bnds) {
>> bundle.start();
>> System.out.println(bundle + " : " +
>> bundle.getState());
>> }
>> } catch (Exception ex) {
>> ex.printStackTrace();
>> }
>> }
>>
>> public Framework getFramework() {
>> return felix;
>> }
>> }
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
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
Re: Felix - File Install
Posted by Guillaume Nodet <gn...@gmail.com>.
It should find the default values in the system proeprties or
framework properties, so if you append those at the end of the felix
configuration file, it should work.
On Wed, Feb 2, 2011 at 17:26, Richard S. Hall <he...@ungoverned.org> wrote:
> On 2/2/11 11:12, Muller, Anthony wrote:
>>
>> Richard,
>>
>> According your advice, I changed the auto-deploy value to "install,
>> start".
>>
>> So, when I print out bundles present in context, I have:
>> org.apache.felix.framework [0] : 32
>> org.apache.felix.fileinstall [1] : 32
>>
>> But, FileInstall is still not properly configured. Where must I put the
>> configuration file? Must I use a specific file name?
>
> I'll let the File Install experts answer that...
>
> -> richard
>
>> Thanks and regards,
>> Anthony
>>
>>
>>
>> "You are only telling the auto-deploy mechanism to install bundles, you
>> want to set the value to "install, start" so that it installs and starts the
>> auto-deploy bundles.
>> -> richard"
>>
>> -----Original Message-----
>> From: Muller, Anthony [mailto:anthony.muller@sap.com]
>> Sent: mercredi 2 février 2011 16:40
>> To: users@felix.apache.org
>> Subject: RE: Felix - File Install
>>
>> I forgot to say that I wrote a configuration file:
>>
>> [conf/config.properties]
>> felix.fileinstall.poll=12000
>> felix.fileinstall.dir=dropins
>> felix.fileinstall.debug=-1
>> felix.fileinstall.bundles.new.start=true
>>
>> But I don't know how FileInstall can be able to find this configuration
>> file... :(
>>
>> Anthony
>>
>>
>> -----Original Message-----
>> From: Muller, Anthony [mailto:anthony.muller@sap.com]
>> Sent: mercredi 2 février 2011 16:36
>> To: users@felix.apache.org
>> Subject: Felix - File Install
>>
>> Hello,
>>
>> I'm trying to use FileInstall but it doesn't work :-/
>>
>> I wrote an eclipse project with an only dependency with Felix.
>>
>> I put "org.apache.felix.fileinstall-3.1.4.jar" in a "bundles" directory
>> and this one is properly deploy by Felix.
>>
>> But I cannot configure FileInstall to manage a "dropins" directory in
>> order to automatically start bundles present here.
>>
>> Thanks for help,
>> Anthony
>>
>>
>> public class FelixLauncher {
>>
>> private final HostActivator activator = new HostActivator();
>>
>> private Framework felix;
>>
>> public FelixLauncher() {
>> // Create a configuration property map.
>> final Map<Object, Object> configMap = new HashMap<Object,
>> Object>();
>>
>> // Create host activator;
>> final List<Object> list = new ArrayList<Object>();
>> list.add(activator);
>> configMap.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP,
>> list);
>> configMap.put(AutoProcessor.AUTO_DEPLOY_DIR_PROPERY,
>> "bundles");
>> configMap.put(AutoProcessor.AUTO_DEPLOY_ACTION_PROPERY,
>> AutoProcessor.AUTO_DEPLOY_INSTALL_VALUE);
>>
>> try {
>> felix = new Felix(configMap);
>> felix.init();
>>
>> AutoProcessor.process(configMap,
>> felix.getBundleContext());
>>
>> felix.start();
>>
>> Bundle[] bnds =
>> felix.getBundleContext().getBundles();
>> for (Bundle bundle : bnds) {
>> bundle.start();
>> System.out.println(bundle + " : " +
>> bundle.getState());
>> }
>> } catch (Exception ex) {
>> ex.printStackTrace();
>> }
>> }
>>
>> public Framework getFramework() {
>> return felix;
>> }
>> }
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix - File Install
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/2/11 11:12, Muller, Anthony wrote:
> Richard,
>
> According your advice, I changed the auto-deploy value to "install, start".
>
> So, when I print out bundles present in context, I have:
> org.apache.felix.framework [0] : 32
> org.apache.felix.fileinstall [1] : 32
>
> But, FileInstall is still not properly configured. Where must I put the configuration file? Must I use a specific file name?
I'll let the File Install experts answer that...
-> richard
> Thanks and regards,
> Anthony
>
>
>
> "You are only telling the auto-deploy mechanism to install bundles, you want to set the value to "install, start" so that it installs and starts the auto-deploy bundles.
> -> richard"
>
> -----Original Message-----
> From: Muller, Anthony [mailto:anthony.muller@sap.com]
> Sent: mercredi 2 février 2011 16:40
> To: users@felix.apache.org
> Subject: RE: Felix - File Install
>
> I forgot to say that I wrote a configuration file:
>
> [conf/config.properties]
> felix.fileinstall.poll=12000
> felix.fileinstall.dir=dropins
> felix.fileinstall.debug=-1
> felix.fileinstall.bundles.new.start=true
>
> But I don't know how FileInstall can be able to find this configuration file... :(
>
> Anthony
>
>
> -----Original Message-----
> From: Muller, Anthony [mailto:anthony.muller@sap.com]
> Sent: mercredi 2 février 2011 16:36
> To: users@felix.apache.org
> Subject: Felix - File Install
>
> Hello,
>
> I'm trying to use FileInstall but it doesn't work :-/
>
> I wrote an eclipse project with an only dependency with Felix.
>
> I put "org.apache.felix.fileinstall-3.1.4.jar" in a "bundles" directory and this one is properly deploy by Felix.
>
> But I cannot configure FileInstall to manage a "dropins" directory in order to automatically start bundles present here.
>
> Thanks for help,
> Anthony
>
>
> public class FelixLauncher {
>
> private final HostActivator activator = new HostActivator();
>
> private Framework felix;
>
> public FelixLauncher() {
> // Create a configuration property map.
> final Map<Object, Object> configMap = new HashMap<Object, Object>();
>
> // Create host activator;
> final List<Object> list = new ArrayList<Object>();
> list.add(activator);
> configMap.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, list);
> configMap.put(AutoProcessor.AUTO_DEPLOY_DIR_PROPERY, "bundles");
> configMap.put(AutoProcessor.AUTO_DEPLOY_ACTION_PROPERY, AutoProcessor.AUTO_DEPLOY_INSTALL_VALUE);
>
> try {
> felix = new Felix(configMap);
> felix.init();
>
> AutoProcessor.process(configMap, felix.getBundleContext());
>
> felix.start();
>
> Bundle[] bnds = felix.getBundleContext().getBundles();
> for (Bundle bundle : bnds) {
> bundle.start();
> System.out.println(bundle + " : " + bundle.getState());
> }
> } catch (Exception ex) {
> ex.printStackTrace();
> }
> }
>
> public Framework getFramework() {
> return felix;
> }
> }
>
> ---------------------------------------------------------------------
> 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
RE: Felix - File Install
Posted by "Muller, Anthony" <an...@sap.com>.
Richard,
According your advice, I changed the auto-deploy value to "install, start".
So, when I print out bundles present in context, I have:
org.apache.felix.framework [0] : 32
org.apache.felix.fileinstall [1] : 32
But, FileInstall is still not properly configured. Where must I put the configuration file? Must I use a specific file name?
Thanks and regards,
Anthony
"You are only telling the auto-deploy mechanism to install bundles, you want to set the value to "install, start" so that it installs and starts the auto-deploy bundles.
-> richard"
-----Original Message-----
From: Muller, Anthony [mailto:anthony.muller@sap.com]
Sent: mercredi 2 février 2011 16:40
To: users@felix.apache.org
Subject: RE: Felix - File Install
I forgot to say that I wrote a configuration file:
[conf/config.properties]
felix.fileinstall.poll=12000
felix.fileinstall.dir=dropins
felix.fileinstall.debug=-1
felix.fileinstall.bundles.new.start=true
But I don't know how FileInstall can be able to find this configuration file... :(
Anthony
-----Original Message-----
From: Muller, Anthony [mailto:anthony.muller@sap.com]
Sent: mercredi 2 février 2011 16:36
To: users@felix.apache.org
Subject: Felix - File Install
Hello,
I'm trying to use FileInstall but it doesn't work :-/
I wrote an eclipse project with an only dependency with Felix.
I put "org.apache.felix.fileinstall-3.1.4.jar" in a "bundles" directory and this one is properly deploy by Felix.
But I cannot configure FileInstall to manage a "dropins" directory in order to automatically start bundles present here.
Thanks for help,
Anthony
public class FelixLauncher {
private final HostActivator activator = new HostActivator();
private Framework felix;
public FelixLauncher() {
// Create a configuration property map.
final Map<Object, Object> configMap = new HashMap<Object, Object>();
// Create host activator;
final List<Object> list = new ArrayList<Object>();
list.add(activator);
configMap.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, list);
configMap.put(AutoProcessor.AUTO_DEPLOY_DIR_PROPERY, "bundles");
configMap.put(AutoProcessor.AUTO_DEPLOY_ACTION_PROPERY, AutoProcessor.AUTO_DEPLOY_INSTALL_VALUE);
try {
felix = new Felix(configMap);
felix.init();
AutoProcessor.process(configMap, felix.getBundleContext());
felix.start();
Bundle[] bnds = felix.getBundleContext().getBundles();
for (Bundle bundle : bnds) {
bundle.start();
System.out.println(bundle + " : " + bundle.getState());
}
} catch (Exception ex) {
ex.printStackTrace();
}
}
public Framework getFramework() {
return felix;
}
}
---------------------------------------------------------------------
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
RE: Felix - File Install
Posted by "Muller, Anthony" <an...@sap.com>.
I forgot to say that I wrote a configuration file:
[conf/config.properties]
felix.fileinstall.poll=12000
felix.fileinstall.dir=dropins
felix.fileinstall.debug=-1
felix.fileinstall.bundles.new.start=true
But I don't know how FileInstall can be able to find this configuration file... :(
Anthony
-----Original Message-----
From: Muller, Anthony [mailto:anthony.muller@sap.com]
Sent: mercredi 2 février 2011 16:36
To: users@felix.apache.org
Subject: Felix - File Install
Hello,
I'm trying to use FileInstall but it doesn't work :-/
I wrote an eclipse project with an only dependency with Felix.
I put "org.apache.felix.fileinstall-3.1.4.jar" in a "bundles" directory and this one is properly deploy by Felix.
But I cannot configure FileInstall to manage a "dropins" directory in order to automatically start bundles present here.
Thanks for help,
Anthony
public class FelixLauncher {
private final HostActivator activator = new HostActivator();
private Framework felix;
public FelixLauncher() {
// Create a configuration property map.
final Map<Object, Object> configMap = new HashMap<Object, Object>();
// Create host activator;
final List<Object> list = new ArrayList<Object>();
list.add(activator);
configMap.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, list);
configMap.put(AutoProcessor.AUTO_DEPLOY_DIR_PROPERY, "bundles");
configMap.put(AutoProcessor.AUTO_DEPLOY_ACTION_PROPERY, AutoProcessor.AUTO_DEPLOY_INSTALL_VALUE);
try {
felix = new Felix(configMap);
felix.init();
AutoProcessor.process(configMap, felix.getBundleContext());
felix.start();
Bundle[] bnds = felix.getBundleContext().getBundles();
for (Bundle bundle : bnds) {
bundle.start();
System.out.println(bundle + " : " + bundle.getState());
}
} catch (Exception ex) {
ex.printStackTrace();
}
}
public Framework getFramework() {
return felix;
}
}
---------------------------------------------------------------------
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
Felix - File Install
Posted by "Muller, Anthony" <an...@sap.com>.
Hello,
I'm trying to use FileInstall but it doesn't work :-/
I wrote an eclipse project with an only dependency with Felix.
I put "org.apache.felix.fileinstall-3.1.4.jar" in a "bundles" directory and this one is properly deploy by Felix.
But I cannot configure FileInstall to manage a "dropins" directory in order to automatically start bundles present here.
Thanks for help,
Anthony
public class FelixLauncher {
private final HostActivator activator = new HostActivator();
private Framework felix;
public FelixLauncher() {
// Create a configuration property map.
final Map<Object, Object> configMap = new HashMap<Object, Object>();
// Create host activator;
final List<Object> list = new ArrayList<Object>();
list.add(activator);
configMap.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, list);
configMap.put(AutoProcessor.AUTO_DEPLOY_DIR_PROPERY, "bundles");
configMap.put(AutoProcessor.AUTO_DEPLOY_ACTION_PROPERY, AutoProcessor.AUTO_DEPLOY_INSTALL_VALUE);
try {
felix = new Felix(configMap);
felix.init();
AutoProcessor.process(configMap, felix.getBundleContext());
felix.start();
Bundle[] bnds = felix.getBundleContext().getBundles();
for (Bundle bundle : bnds) {
bundle.start();
System.out.println(bundle + " : " + bundle.getState());
}
} catch (Exception ex) {
ex.printStackTrace();
}
}
public Framework getFramework() {
return felix;
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: New OSGi presentation
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/31/11 14:28, teemu kanstren wrote:
> 2011/1/31 Rémon. Sinnema<rs...@yahoo.com>
>
>> ----- Original Message ----
>>
>> From: teemu kanstren<tk...@gmail.com>
>> To: users@felix.apache.org
>> Sent: Mon, January 31, 2011 9:01:54 AM
>> Subject: Re: New OSGi presentation
>>
>>> I think it would be great
>>> to see some "best practices" documented somewhere for how to deal with
>> this.
>>
>> I think Neil Bartlett has done a great job with that:
>> http://njbartlett.name/2010/08/30/osgi-readiness-loading-classes.html
>>
>> Thanks for the link. This is some good stuff. I bookmarked this now, but it
> would be nice if some such links were available on a website such as Felix
> to make it easier to find them.
Unfortunately, we haven't yet convinced everyone that they should
contribute everything directly to Felix. ;-)
-> richard
> Teemu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: New OSGi presentation
Posted by teemu kanstren <tk...@gmail.com>.
2011/1/31 Rémon. Sinnema <rs...@yahoo.com>
> ----- Original Message ----
>
> From: teemu kanstren <tk...@gmail.com>
> To: users@felix.apache.org
> Sent: Mon, January 31, 2011 9:01:54 AM
> Subject: Re: New OSGi presentation
>
> > I think it would be great
> > to see some "best practices" documented somewhere for how to deal with
> this.
>
> I think Neil Bartlett has done a great job with that:
> http://njbartlett.name/2010/08/30/osgi-readiness-loading-classes.html
>
> Thanks for the link. This is some good stuff. I bookmarked this now, but it
would be nice if some such links were available on a website such as Felix
to make it easier to find them.
Teemu
Re: New OSGi presentation
Posted by "Rémon. Sinnema" <rs...@yahoo.com>.
----- Original Message ----
From: teemu kanstren <tk...@gmail.com>
To: users@felix.apache.org
Sent: Mon, January 31, 2011 9:01:54 AM
Subject: Re: New OSGi presentation
> I think it would be great
> to see some "best practices" documented somewhere for how to deal with this.
I think Neil Bartlett has done a great job with that:
http://njbartlett.name/2010/08/30/osgi-readiness-loading-classes.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: New OSGi presentation
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/31/11 3:01, teemu kanstren wrote:
> 2011/1/28 Richard S. Hall<he...@ungoverned.org>
>
>> On 1/28/11 8:56, teemu kanstren wrote:
>>
>>> Thanks Richard for the nice set of slides and congrats. Just a few
>>> comments
>>> on the slides (I admit I do not know that much about OSGI but at least I
>>> read some docs sometime :))
>>>
>>> -In the beginning you mention legacy code and how it is naughty to use
>>> stuff
>>> like Class.forName. I think several frameworks use such reflection tricks
>>> and whether they are legacy code or not sometimes I need to use them.
>>> Recently my experience has been so at least with Apache XMLRPC and some
>>> REST
>>> frameworks (Jersey/Restlet). This seems really hard to fix when there is
>>> no
>>> support from the framework but if you need that technology what do you do?
>>> Is everything legacy if it is not OSGI tested?
>>>
>> Legacy code is anything that was not written with OSGi in mind, but
>> problematic legacy code is code that makes assumptions about type visibility
>> or code lifecycle.
>>
>> Legacy code is not always problematic. If you just have a library that
>> provides types and doesn't try to dynamically load other classes, then it
>> will probably work fine once you convert it to a bundle.
>>
>>
> OK, thanks for the clarifications on the slides! Since, for me, this seems
> to be one of the most common issues to run into, I think it would be great
> to see some "best practices" documented somewhere for how to deal with this.
> Perhaps even some pointers for "if you need this, here are some experiences
> from some user on how to make it work..".
The slides do include suggestions if you need to dynamically load classes...
> Could be general cases or specific
> to some libraries etc. Would greatly help me "ignore" OSGI. Not really
> something to do for your slides but I think to help people use OSGI these
> are maybe the more painful things that they will need to manage. For me it
> has been anyway.
More documentation would definitely be welcome.
>> -You talk about lifecycle and how you can implement your own, mentioning
>>> that the rules will just be enforced by "you" then. The previous slide
>>> talks
>>> about resource management. Does OSGI actually enforce some resource
>>> management rules such as checking what threads/files/etc are created and
>>> when?
>>>
>> No, there is no enforcement, mainly because this is difficult, if not
>> impossible, to do in Java. For OSGi, the bundle activator is the contract
>> that says you won't do stuff like threads, sockets, etc. until you are
>> started and not after you are stopped.
>>
>>
> The resource management would be great, but I agree it is too hard without
> better support from the JVM. But for the slides I was left a bit wondering
> what was the contract management that Felix (or OSGI in general) would do
> for me. Of course, someone will probably present the slides so that should
> be no problem to explain.
In the slides, I specifically say that your code should not use
resources before its start() is called and should not use any after
stop() is called.
-> richard
> Teemu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: New OSGi presentation
Posted by teemu kanstren <tk...@gmail.com>.
2011/1/28 Richard S. Hall <he...@ungoverned.org>
> On 1/28/11 8:56, teemu kanstren wrote:
>
>> Thanks Richard for the nice set of slides and congrats. Just a few
>> comments
>> on the slides (I admit I do not know that much about OSGI but at least I
>> read some docs sometime :))
>>
>> -In the beginning you mention legacy code and how it is naughty to use
>> stuff
>> like Class.forName. I think several frameworks use such reflection tricks
>> and whether they are legacy code or not sometimes I need to use them.
>> Recently my experience has been so at least with Apache XMLRPC and some
>> REST
>> frameworks (Jersey/Restlet). This seems really hard to fix when there is
>> no
>> support from the framework but if you need that technology what do you do?
>> Is everything legacy if it is not OSGI tested?
>>
>
> Legacy code is anything that was not written with OSGi in mind, but
> problematic legacy code is code that makes assumptions about type visibility
> or code lifecycle.
>
> Legacy code is not always problematic. If you just have a library that
> provides types and doesn't try to dynamically load other classes, then it
> will probably work fine once you convert it to a bundle.
>
>
OK, thanks for the clarifications on the slides! Since, for me, this seems
to be one of the most common issues to run into, I think it would be great
to see some "best practices" documented somewhere for how to deal with this.
Perhaps even some pointers for "if you need this, here are some experiences
from some user on how to make it work..". Could be general cases or specific
to some libraries etc. Would greatly help me "ignore" OSGI. Not really
something to do for your slides but I think to help people use OSGI these
are maybe the more painful things that they will need to manage. For me it
has been anyway.
>
> -You talk about lifecycle and how you can implement your own, mentioning
>> that the rules will just be enforced by "you" then. The previous slide
>> talks
>> about resource management. Does OSGI actually enforce some resource
>> management rules such as checking what threads/files/etc are created and
>> when?
>>
>
> No, there is no enforcement, mainly because this is difficult, if not
> impossible, to do in Java. For OSGi, the bundle activator is the contract
> that says you won't do stuff like threads, sockets, etc. until you are
> started and not after you are stopped.
>
>
The resource management would be great, but I agree it is too hard without
better support from the JVM. But for the slides I was left a bit wondering
what was the contract management that Felix (or OSGI in general) would do
for me. Of course, someone will probably present the slides so that should
be no problem to explain.
Teemu
Re: New OSGi presentation
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/28/11 8:56, teemu kanstren wrote:
> Thanks Richard for the nice set of slides and congrats. Just a few comments
> on the slides (I admit I do not know that much about OSGI but at least I
> read some docs sometime :))
>
> -In the beginning you mention legacy code and how it is naughty to use stuff
> like Class.forName. I think several frameworks use such reflection tricks
> and whether they are legacy code or not sometimes I need to use them.
> Recently my experience has been so at least with Apache XMLRPC and some REST
> frameworks (Jersey/Restlet). This seems really hard to fix when there is no
> support from the framework but if you need that technology what do you do?
> Is everything legacy if it is not OSGI tested?
Legacy code is anything that was not written with OSGi in mind, but
problematic legacy code is code that makes assumptions about type
visibility or code lifecycle.
Legacy code is not always problematic. If you just have a library that
provides types and doesn't try to dynamically load other classes, then
it will probably work fine once you convert it to a bundle.
> -You talk about lifecycle and how you can implement your own, mentioning
> that the rules will just be enforced by "you" then. The previous slide talks
> about resource management. Does OSGI actually enforce some resource
> management rules such as checking what threads/files/etc are created and
> when?
No, there is no enforcement, mainly because this is difficult, if not
impossible, to do in Java. For OSGi, the bundle activator is the
contract that says you won't do stuff like threads, sockets, etc. until
you are started and not after you are stopped.
> -You discuss transitive dependencies and uses constraints. What is a "uses"
> constraint? I do not see it explained in the slides and I though it was only
> import or export in OSGI.
This isn't explained in the slides. I am still planning to improve those
last few slides. See the discussion here:
http://www.osgi.org/blog/2011/01/error-messages.html
In short, a "uses" constraint is a package-to-package dependency. If you
think about Import-Package and Export-Package, these express
bundle-to-package dependencies. "Uses" constraints go one level deeper
and express the internal package-to-package dependencies. For example,
the org.osgi.service.http package has a "uses" constraint on the
javax.servlet package, because it uses the javax.servlet.Servlet type.
This level of dependency information is necessary to ensure that bundles
do not see more than one version of the same type. Assume I have an HTTP
Service bundle exporting org.osgi.service.http and importing
javax.servlet. Then assume I have a client bundle importing
org.osgi.service.http and javax.servlet. If you satisfy these
dependencies separately, it is possible that the client bundle could
wire to a different version of javax.servlet than the HTTP Service
bundle. If this happened the client and the HTTP Service would receive
class cast exceptions when collaborating. "Uses" constraints make it
possible to detect such situations and avoid them.
> -Thanks for the few pointers on using the gogo shell. I never found such an
> explanation of how to use the gogo shell on the Felix website so I am always
> completely lost with what it is and what I could do with it :). Maybe you
> could write something similar for the website, just a bit more extensive?
This would probably be worthwhile too. :-)
-> richard
> That's all for me..
>
> Teemu
>
> 2011/1/20 Richard S. Hall<he...@ungoverned.org>
>
>> After some recent experiences I had with some developers trying to use OSGi
>> without even understanding the basics, I decided to work on a presentation
>> highlighting what you must understand about OSGi to use it. Please find it
>> on the presentations page:
>>
>> http://felix.apache.org/site/presentations.html
>>
>> The direct link to the PDF is here:
>>
>>
>> http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
>>
>> Comments welcome.
>>
>> -> richard
>>
>> ---------------------------------------------------------------------
>> 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
Re: New OSGi presentation
Posted by Justin Edelson <ju...@justinedelson.com>.
I had this feedback as well. 'uses' constraints are really important and actually pretty reasonable once you understand them. Karl and Marcel's presentation from OSGi DevCon did a good job (IMHO) of explaining them.
Justin
On Jan 28, 2011, at 8:56 AM, teemu kanstren <tk...@gmail.com> wrote:
> -You discuss transitive dependencies and uses constraints. What is a "uses"
> constraint? I do not see it explained in the slides and I though it was only
> import or export in OSGI.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: New OSGi presentation
Posted by teemu kanstren <tk...@gmail.com>.
Thanks Richard for the nice set of slides and congrats. Just a few comments
on the slides (I admit I do not know that much about OSGI but at least I
read some docs sometime :))
-In the beginning you mention legacy code and how it is naughty to use stuff
like Class.forName. I think several frameworks use such reflection tricks
and whether they are legacy code or not sometimes I need to use them.
Recently my experience has been so at least with Apache XMLRPC and some REST
frameworks (Jersey/Restlet). This seems really hard to fix when there is no
support from the framework but if you need that technology what do you do?
Is everything legacy if it is not OSGI tested?
-You talk about lifecycle and how you can implement your own, mentioning
that the rules will just be enforced by "you" then. The previous slide talks
about resource management. Does OSGI actually enforce some resource
management rules such as checking what threads/files/etc are created and
when?
-You discuss transitive dependencies and uses constraints. What is a "uses"
constraint? I do not see it explained in the slides and I though it was only
import or export in OSGI.
-Thanks for the few pointers on using the gogo shell. I never found such an
explanation of how to use the gogo shell on the Felix website so I am always
completely lost with what it is and what I could do with it :). Maybe you
could write something similar for the website, just a bit more extensive?
That's all for me..
Teemu
2011/1/20 Richard S. Hall <he...@ungoverned.org>
> After some recent experiences I had with some developers trying to use OSGi
> without even understanding the basics, I decided to work on a presentation
> highlighting what you must understand about OSGi to use it. Please find it
> on the presentations page:
>
> http://felix.apache.org/site/presentations.html
>
> The direct link to the PDF is here:
>
>
> http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf
>
> Comments welcome.
>
> -> richard
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>