from:"Milen Dyankov"

Re: Re: Felix and Pax Logging

2017-11-30 Thread Milen Dyankov

Have you seen
http://karaf.922171.n3.nabble.com/Using-Log4j-mail-appender-in-Karaf-with-pax-logging-td3180892.html
It's about Karaf but I think the concept should apply to OSGi in general.

On Thu, Nov 30, 2017 at 1:19 PM, daniel stieger <daniel.stie...@gmx.at>
wrote:

>
>
> Hi Milen, hi Erwin,
>
> thanks for your comments. Indeed, i could get pax up and running with the
> config in the file-install dir, the pax itself in the bundles dir.
> Nevertheless, getting the smtp append up and running is realy tricky. I
> read a lot of stuff regarding the javax.activiation and javax.mail
> packages, which are not "out of the box" suitable for osgi..
>
> My struggle wil go on... i will try a couple of things.
>
> Thanks for your help,
> Daniel
>
>
> Gesendet: Mittwoch, 29. November 2017 um 19:49 Uhr
> Von: "Milen Dyankov" <milendyan...@gmail.com>
> An: users@felix.apache.org
> Betreff: Re: Felix and Pax Logging
> I think in order to do that you need FileInstall (
> http://felix.apache.org/documentation/subprojects/
> apache-felix-file-install.html).
> You need to configure it to watch the folder(s) you want via system
> property `felix.fileinstall.dir`.
> Then you can place a file `org.ops4j.pax.logging.cfg` in that folder and it
> should (re)configure Pax Logging.
>
> On Wed, Nov 29, 2017 at 5:42 PM, daniel stieger <daniel.stie...@gmx.at>
> wrote:
>
> >
> > Gentlemen,
> >
> > i feel realy bad to ask such a beginner s question, but after 4 hours i m
> > giving up.
> >
> > I just use a plain felix installation and added the config admin and the
> > pax logging framework (api + service). However, i have not found out how
> to
> > configure pax logging to use a file...
> >
> > * placed org.ops4j.pax.logging.properties file to ./confg
> > * placed org.ops4j.pax.logging.cfg file to ./bundle
> >
> > and to almost all other dirs .. .. i was able to
> > set org.ops4j.pax.logging.DefaultServiceLog.level=ERROR
> > int ./config/config.propeties That did work! also tried to adjust with
> > "org.ops4j.pax.logging.log4j.rootLogger =  " in this very file ..
> > doesn't work either.
> >
> > How could i adjust the pax settings? Is there also a way to check those
> > settings via gogo shell?
> >
> >
> > Any hint apreciated ..
> > Daniel
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
> >
>
>
> --
> http://about.me/milen[http://about.me/milen]
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


-- 
http://about.me/milen

Re: Felix and Pax Logging

2017-11-29 Thread Milen Dyankov

I think in order to do that you need FileInstall (
http://felix.apache.org/documentation/subprojects/apache-felix-file-install.html).
You need to configure it to watch the folder(s) you want via system
property `felix.fileinstall.dir`.
Then you can place a file `org.ops4j.pax.logging.cfg` in that folder and it
should (re)configure Pax Logging.

On Wed, Nov 29, 2017 at 5:42 PM, daniel stieger 
wrote:

>
> Gentlemen,
>
> i feel realy bad to ask such a beginner s question, but after 4 hours i m
> giving up.
>
> I just use a plain felix installation and added the config admin and the
> pax logging framework (api + service). However, i have not found out how to
> configure pax logging to use a file...
>
> * placed org.ops4j.pax.logging.properties   file to ./confg
> * placed org.ops4j.pax.logging.cfgfile to ./bundle
>
> and to almost all other dirs ..  .. i was able to
> set org.ops4j.pax.logging.DefaultServiceLog.level=ERROR
> int ./config/config.propeties That did work! also tried to adjust with
> "org.ops4j.pax.logging.log4j.rootLogger = " in this very file ..
> doesn't work either.
>
> How could i adjust the pax settings? Is there also a way to check those
> settings via gogo shell?
>
>
> Any hint apreciated ..
> Daniel
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


-- 
http://about.me/milen

Re: Fw: Mem Leak

2017-11-20 Thread Milen Dyankov

Have you tried to refresh (there is gogo command for that) your runtime?
AFAIK some wirings remain after the bundle is unistalled until the
framework is refreshed.

On Mon, Nov 20, 2017 at 1:59 PM, daniel stieger 
wrote:

>
>
>
>
> Gesendet: Montag, 20. November 2017 um 13:58 Uhr
> Von: "daniel stieger" 
> An: users@felix.apache.org
> Betreff: Mem Leak
>
> Gentlemen,
>
> i m just struggeling with some bundle unloading problem. Maybe someone can
> point me towards the right direction for some research.
>
> Here s my situation:
> (1) I created an osgi bundle which does not export anything. I m just
> using spring ioc to set up some beans .. (ver 3.0.5)
> (2) I deploy this bundle via apache felix file install to a felix 5.6.8
> (3) i uninstall that very bundle via shell ...
> (4) then i use visual vm to fore a garbage collection, wait some time and
> force again
> (5) then i check with visualvm if specific classes from my bundle are
> still around.
>
>
> * Well, yes there are some classes still around: but only enum constants
> as instances, all other instance counts are 0
> * The classloader used by my bundle is also around
> * But everywhere i check GC-Roots, the visual vm tells me "No gc-root
> found"
> * Also on the classloader itself .. BundelWiringImpl$BundleClassLoader it
> tells me that "no gc-root found"
>
>
> Any idea how i can investigate this issue further? Clearly, after
> uninstalling the bundle, i do want to get rid of all classes loaded by that
> bundle..
>
> Any help apreciated,
> Daniel
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


-- 
http://about.me/milen

Re: API baselining with maven-bundle-plugin

2017-06-23 Thread Milen Dyankov

>
> you will be able to build another 1.0.0 locally, but you will not be able
> to release it again


I think that depends on particular Maven repository and it's configuration.
While this is probably true for Central (not sure but would assume so) a
local Nexus repo can be configured to allow re-releasing.

On Fri, Jun 23, 2017 at 7:30 PM, Neil Bartlett  wrote:

> Hi Tom,
>
> I’m very glad that you’re enjoying the baselining feature of Bndtools so
> much!
>
> I think your expectations are reasonable but we just aren’t quite there
> with bnd/Maven integration.
>
> Bndtools is able to give you immediate baselining errors, but it currently
> only works when bndlib is called directly by Bndtools. In a Maven workspace
> using M2Eclipse, the bundle is built by maven-bundle-plugin or
> bnd-maven-plugin, which of course use bndlib internally, but Bndtools is
> isolated from it by a layer of Maven. The bnd-maven-plugin is run
> incrementally by M2E but we don’t yet have a way to catch the baselining
> errors from bnd-maven-plugin and report them in the IDE. In the future we
> *may* be able to do this, I’m not sure.
>
> So, you won’t get immediate feedback on versioning errors but I would
> still expect the build to be affected as follows:
>
> 1. Package versions will be checked and will fail the build when they are
> incorrect. This is a feature of bnd surfaced through the bnd-maven-plugin.
>
> 2. If you have released version 1.0.0. (i.e. non-SNAPSHOT) of a bundle
> with Maven then you will be able to build another 1.0.0 locally, but you
> will not be able to release it again — this is a built-in feature of Maven.
> At this point you will be forced to bump your bundle version, so it is
> slightly less powerful than bnd baselining which will not even permit you
> to build locally bundle 1.0.0 if it has a delta against the released bundle.
>
> Still, you don’t have to *remember* to bump your versions, the build tool
> will force you to do it eventually.
>
> If a Maven developer would like to check and correct my understanding —
> particularly on point 2 above — please do so!
>
> Thanks,
> Neil
>
>
>
> > On 23 Jun 2017, at 14:26, Tom Quarendon  worldprogramming.com> wrote:
> >
> > So here's what I've just done in bndtools.
> >
> > Created a project that has three bundles in it, test.api, test.command,
> test.provider. All versions (package, bundle) are initialised to 1.0.0.
> > Set up the project so that it will release to a maven repository.
> > Run the "gradle release" command line option.
> > I now have a "1.0.0" version of the bundle in my maven repository.
> > Set up baselining. This requires nothing more than adding:
> > "-baseline:*"
> > To my build.bnd configuration file. I don't have to say "baseline
> against version X" etc and keep that up to date.
> >
> > Then, literally ALL I did was change the method signature on one of the
> methods.
> > I get, immediately, errors such as:
> > The method 'say(java.lang.String)' was removed, which requires a MAJOR
> change to the package.
> > versioning.test.api: The bundle version (1.0.0/1.0.0) is too low, must
> be at least 2.0.0
> >
> > I resolve all of the issues and I now have my package and bundle version
> numbers at 2.0.0, which is what they need to be given the change in the
> source code.
> > I get the same errors if I run the gradle build that bndtools produces
> for you.
> >
> > Note, I didn't first bump the versions, then make the code change. ALL I
> did was make the code change.
> >
> > So I don't think what I'm trying to do is unreasonable. I don't have to
> remember to bump any versions, I get build failures unless I do. Perfect.
> >
> > This is what I'm trying to replicate, but in a project that wasn't
> originally written with bndtools. I thought maven might be a simpler route
> as it's used elsewhere, and I naively thought I might be able to do it
> using the bnd plugin for maven, since it exposes the baseline facility.
> >
> > Clearly I can't. Clearly my world view doesn't align with maven's.
> That's fine.
> >
> > I will refocus my efforts on trying to do the same thing in gradle,
> where I think I will have more success.
> >
> >
> >
> > -Original Message-
> > From: Justin Edelson [mailto:jus...@justinedelson.com]
> > Sent: 23 June 2017 14:00
> > To: users@felix.apache.org
> > Subject: Re: API baselining with maven-bundle-plugin
> >
> > On Fri, Jun 23, 2017 at 3:23 AM Tom Quarendon < tom.quarendon@
> worldprogramming.com> wrote:
> >
> >> I get immutable releases. I'm not trying to redefine what 1.0.0 is
> >> with different source code. In fact quite the opposite. I want it to
> >> *prevent me from doing do*. The maven bnd plugin doesn't
> >>
> >> It's the difference between:
> >>  "I'm trying to build something that the user wants to call 1.0.0. As
> >> part of that process I'll check whether it conflicts with what is
> >> currently 1.0.0, and if it does I'll fail, not actually creating the
> >>

Re: setting the objectclassdefinition from felix file install

2016-10-03 Thread Milen Dyankov

Isn't it so that if your configuration is NOT mandatory the @Activate
method will get the default and @Modified method will get the one from the
file later on?
Or am I misinterpreting the question?

On Mon, Oct 3, 2016 at 7:38 PM, Raymond Auge 
wrote:

> Well, I'm not sure about that but because you've not named a pid in your
> component, it's not associating that with the configuration. Honestly, I'm
> not sure the pid in the OCD will get interpreted as being the pid of the
> configuration. My gut tells me it's not doing that. So you still need to
> name the pid in your component.
>
> Someone else may correct me of course. However, it should be simple to
> assert by adding the configurationPid property on the component and seeing
> if it does eventually bind.
>
> - Ray
>
> On Mon, Oct 3, 2016 at 1:27 PM, David Daniel 
> wrote:
>
> > Thank you,  I think I may be wrong somewhere else then.  I have this in
> my
> > logs
> >
> > *DEBUG*
> > listConfigurations(filter=(felix.fileinstall.filename=
> > file:/media/david/abcd2f06-6ee4-4c5a-8c80-e4023ec8a52c/
> > development/asae/asae-base/packaging/all/etc/com.marklogic.cfg))
> > *DEBUG* Listing configurations matching
> > (felix.fileinstall.filename=file:/media/david/abcd2f06-
> > 6ee4-4c5a-8c80-e4023ec8a52c/development/asae/asae-base/
> > packaging/all/etc/com.marklogic.cfg)
> > Creating configuration from com.marklogic.cfg
> > *DEBUG* getConfiguration(pid=com.marklogic, location=null)
> >
> > does setting the pid as I did above not do what I thought it would do.
> >
> >
> > On Mon, Oct 3, 2016 at 1:12 PM, Raymond Auge 
> > wrote:
> >
> > > Make the configuration mandatory in the component!
> > >
> > > - Ray
> > >
> > > On Mon, Oct 3, 2016 at 1:08 PM, David Daniel <
> > david.daniel.1...@gmail.com>
> > > wrote:
> > >
> > > > I have an object class definition
> > > >
> > > > @ObjectClassDefinition(name = "Marklogic Configuration",
> > > > pid = "com.marklogic")
> > > > @interface MarklogicConfig {
> > > > String content_host() default "localhost";
> > > > String content_username() default "admin";
> > > > String content_pword() default "**";
> > > > String content_dbname() default "";
> > > > }
> > > >
> > > > and a component
> > > >
> > > > @Component(service = {MarkLogicConnector.class})
> > > > @Designate(ocd = MarklogicConfig.class)
> > > > public class MarkLogicConnector {
> > > >
> > > > I have the felix file install bundle installed and working.  It seems
> > > like
> > > > it is loading com.marklogic.cfg correctly.  Is there a way to make
> sure
> > > > that the file is loaded before the configuration is passed into the
> > > > activate method.  I seem to be getting the default values rather than
> > the
> > > > configured ones that came from fileinstall.
> > > >
> > >
> > >
> > >
> > > --
> > > *Raymond Augé* 
> > >  (@rotty3000)
> > > Senior Software Architect *Liferay, Inc.* 
> > >  (@Liferay)
> > > Board Member & EEG Co-Chair, OSGi Alliance 
> > > (@OSGiAlliance)
> > >
> >
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>



-- 
http://about.me/milen

[Ann] Modularity Conference in Darmstadt Germany : ModConf

2016-08-22 Thread Milen Dyankov

Hi guys,

As some of you may have heard (via other communication channels) we at
Liferay are trying to put together a new event in Europe related to
modularity. This new event, called Modconf
 will be a one-day (Nov
15) "conference within a conference" (at least for its first edition) in
Darmstadt, Germany.

While hosted by Liferay, it will not cover our products but focus on
anything related to modularity (mostly Java but also front-end,
architecture, distributed systems, IoT, ...) and we are happy to have OSGi
Alliance supporting the idea
.

I know many of you have huge experience in this area. It would be great if
you can propose a talk or workshop, to help us make this interesting and
valuable event. The CFP  was extended till
September 7th so you still have some time. Obviously we would like you to
see you there even if you don't present and just want to learn and network
with other like-minded fellows.

Thank you and hope to see some of you there.

Re: Specifying dependency between a bundle and a fragment bundle

2016-01-14 Thread Milen Dyankov

I'm not sure what you mean by "via services". As for subsystems, my
understanding is this is more of a packaging/delivery option. It may help
but I still need a soliton that will work for deploying individual bundles.

Anyway, I experimented a bit more and it seams it's fully possible to use
requirement and capabilities with fragment bundles.
I don't know why it wasn't working before but my understanding that
capabilities related headers in fragment bundle are applied to the host
bundle is wrong!

So, by putting

Fragment-Host: original.ui.bundle
Provide-Capability: myUI
Require-Capability: myService

in my UI bundle and then in my service bundle

Provide-Capability: myService
Require-Capability: myUI

I can actually define the dependency I need.
With that in place, I can uninstall (too bad I can not only unresolve) my
service bundle if my service fails. There are still some quirks with
refreshing the original UI bundle but it generally works.
It's probably not the best solution but I couldn't figure out anything
better so far.

Thanks for your help!
Milen


On Wed, Jan 13, 2016 at 3:02 PM, CLEMENT Jean-Philippe <
jean-philippe.clem...@fr.thalesgroup.com> wrote:

> I would have made this via services, but there might be other ways such as
> subsystems (?)
>
> JP
>
> [@@ OPEN @@]
>
>
> -Message d'origine-
> De : Milen Dyankov [mailto:milendyan...@gmail.com]
> Envoyé : mercredi 13 janvier 2016 14:49
> À : users@felix.apache.org
> Objet : Re: Specifying dependency between a bundle and a fragment bundle
>
> Conceptually I guess you can put it that way, yes.
>
> On Wed, Jan 13, 2016 at 2:43 PM, CLEMENT Jean-Philippe <
> jean-philippe.clem...@fr.thalesgroup.com> wrote:
>
> > Do you mean ensure that fragments and services are deployed as a
> > single transaction?
> >
> > JP
> >
> > [@@ OPEN @@]
> >
> >
> > -Message d'origine-
> > De : Milen Dyankov [mailto:milendyan...@gmail.com] Envoyé : mercredi
> > 13 janvier 2016 13:57 À : users@felix.apache.org Objet : Re:
> > Specifying dependency between a bundle and a fragment bundle
> >
> > Thank you for your thoughts regarding replacing the service. However
> > that is not really my concern. There are 2 aspects in the picture -
> > the service itself and the UI to communicate with it.
> > In traditional layered architecture one would refer to those as
> > service layer an UI layer. Both are developed independenty and in more
> > complex scenarios there could be N bundles providing UIs for working
> > with M bundles providing services. In non-OSGi environment if I start
> > application having correct modules (jar files and resources on the
> > classpath) at runtime, I am kind of guaranteed to have a consistent
> > change in both layers. In OSGi (or any dynamic modular system I guess)
> > one change can be applied and the other one not (due to configuration,
> > resolve issues, removed dependencies, ...) which can lead to UI
> > functionality not matching the actual underlying services providing
> > it. So what I'm struggling with is finding a way to keep the changes
> > consistent across both layers. As in this particular case the changes
> > to the UI layer are applied via fragment bundles and the changes to
> > the service layer are applied by providing "regular" bundles, I'm
> > looking for a way to express the relationship between those. I guess
> > using Requirements and Capabilities would be perfect but to my
> understanding you can not use it for fragments.
> >
> >
> >
> > On Wed, Jan 13, 2016 at 1:24 PM, CLEMENT Jean-Philippe <
> > jean-philippe.clem...@fr.thalesgroup.com> wrote:
> >
> > > I'm not too sure what you need, but I would say first that you
> > > consider what you have (a text file) rather than what you need (a
> > > service or services). It seems you see things through the provider
> > > instead of the consumer.
> > >
> > > So, you have a button which calls a service S. Fine. Then you want S
> > > to be the best service. So you just have to implement a service S
> > > which is a proxy to T services and which will forward calls to the
> > > best
> > T service.
> > >
> > > You can even reuse S instead of another T service. So, S is a proxy
> > > to other S services. The proxy has the better ranking in order the
> > > button to "find it". The proxy has to exclude itself from S service
> candidates.
> > >
> > > ...just a quick thought...
> > >
> > > JP
> > >
> > > [@@ OPEN @@]
> > >
> > > -Message d'origine-

Specifying dependency between a bundle and a fragment bundle

2016-01-13 Thread Milen Dyankov

Lets say I have a UI bundle that renders a button from template. The
template is just a text file(s) inside UI bundle. Clicking the button calls
a service (for the purpose of this example say one with the highest rank).

The requirement is: change both the service that is called and the button
in consistent manner.

The first part is easy:
 - To change the service one can simply provide a new bundle (call it S)
containing the new service implementation (with higher rank or whatever
else it takes to make it the one that service registry will give to the UI
bundle).
 - To change the button (or even replace it with something else) one can
provide a fragment bundle (call it FB) with updated template file(s).

The question is, how to keep those consistent? That is, make sure that
either both S and FB are applied or none of them (lets assume S will
somehow ensure the service is registered or stop itself if it can't do so)!

It seams one needs to somehow declare a bidirectional dependency (I hate
the way it sounds, but that's what it in fact is, isn't it) between a
bundle and a fragment bundle. AFAIK this is not really possible as anything
specified in fragment is applied to the host! Has anyone faced similar
challenge before?


-- 
http://about.me/milen

Re: Specifying dependency between a bundle and a fragment bundle

2016-01-13 Thread Milen Dyankov

Conceptually I guess you can put it that way, yes.

On Wed, Jan 13, 2016 at 2:43 PM, CLEMENT Jean-Philippe <
jean-philippe.clem...@fr.thalesgroup.com> wrote:

> Do you mean ensure that fragments and services are deployed as a single
> transaction?
>
> JP
>
> [@@ OPEN @@]
>
>
> -----Message d'origine-
> De : Milen Dyankov [mailto:milendyan...@gmail.com]
> Envoyé : mercredi 13 janvier 2016 13:57
> À : users@felix.apache.org
> Objet : Re: Specifying dependency between a bundle and a fragment bundle
>
> Thank you for your thoughts regarding replacing the service. However that
> is not really my concern. There are 2 aspects in the picture - the service
> itself and the UI to communicate with it.
> In traditional layered architecture one would refer to those as service
> layer an UI layer. Both are developed independenty and in more complex
> scenarios there could be N bundles providing UIs for working with M bundles
> providing services. In non-OSGi environment if I start application having
> correct modules (jar files and resources on the classpath) at runtime, I am
> kind of guaranteed to have a consistent change in both layers. In OSGi (or
> any dynamic modular system I guess) one change can be applied and the other
> one not (due to configuration, resolve issues, removed dependencies, ...)
> which can lead to UI functionality not matching the actual underlying
> services providing it. So what I'm struggling with is finding a way to keep
> the changes consistent across both layers. As in this particular case the
> changes to the UI layer are applied via fragment bundles and the changes to
> the service layer are applied by providing "regular" bundles, I'm looking
> for a way to express the relationship between those. I guess using
> Requirements and Capabilities would be perfect but to my understanding you
> can not use it for fragments.
>
>
>
> On Wed, Jan 13, 2016 at 1:24 PM, CLEMENT Jean-Philippe <
> jean-philippe.clem...@fr.thalesgroup.com> wrote:
>
> > I'm not too sure what you need, but I would say first that you
> > consider what you have (a text file) rather than what you need (a
> > service or services). It seems you see things through the provider
> > instead of the consumer.
> >
> > So, you have a button which calls a service S. Fine. Then you want S
> > to be the best service. So you just have to implement a service S
> > which is a proxy to T services and which will forward calls to the best
> T service.
> >
> > You can even reuse S instead of another T service. So, S is a proxy to
> > other S services. The proxy has the better ranking in order the button
> > to "find it". The proxy has to exclude itself from S service candidates.
> >
> > ...just a quick thought...
> >
> > JP
> >
> > [@@ OPEN @@]
> >
> > -Message d'origine-
> > De : Milen Dyankov [mailto:milendyan...@gmail.com] Envoyé : mercredi
> > 13 janvier 2016 11:10 À : users@felix.apache.org Objet : Specifying
> > dependency between a bundle and a fragment bundle
> >
> > Lets say I have a UI bundle that renders a button from template. The
> > template is just a text file(s) inside UI bundle. Clicking the button
> > calls a service (for the purpose of this example say one with the
> highest rank).
> >
> > The requirement is: change both the service that is called and the
> > button in consistent manner.
> >
> > The first part is easy:
> >  - To change the service one can simply provide a new bundle (call it
> > S) containing the new service implementation (with higher rank or
> > whatever else it takes to make it the one that service registry will
> > give to the UI bundle).
> >  - To change the button (or even replace it with something else) one
> > can provide a fragment bundle (call it FB) with updated template file(s).
> >
> > The question is, how to keep those consistent? That is, make sure that
> > either both S and FB are applied or none of them (lets assume S will
> > somehow ensure the service is registered or stop itself if it can't do
> so)!
> >
> > It seams one needs to somehow declare a bidirectional dependency (I
> > hate the way it sounds, but that's what it in fact is, isn't it)
> > between a bundle and a fragment bundle. AFAIK this is not really
> > possible as anything specified in fragment is applied to the host! Has
> > anyone faced similar challenge before?
> >
> >
> > --
> > http://about.me/milen
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
>
>
>
> --
> http://about.me/milen
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>



-- 
http://about.me/milen

Re: Specifying dependency between a bundle and a fragment bundle

2016-01-13 Thread Milen Dyankov

Thank you for your thoughts regarding replacing the service. However that
is not really my concern. There are 2 aspects in the picture - the service
itself and the UI to communicate with it.
In traditional layered architecture one would refer to those as service
layer an UI layer. Both are developed independenty and in more complex
scenarios there could be N bundles providing UIs for working with M bundles
providing services. In non-OSGi environment if I start application having
correct modules (jar files and resources on the classpath) at runtime, I am
kind of guaranteed to have a consistent change in both layers. In OSGi (or
any dynamic modular system I guess) one change can be applied and the other
one not (due to configuration, resolve issues, removed dependencies, ...)
which can lead to UI functionality not matching the actual underlying
services providing it. So what I'm struggling with is finding a way to keep
the changes consistent across both layers. As in this particular case the
changes to the UI layer are applied via fragment bundles and the changes to
the service layer are applied by providing "regular" bundles, I'm looking
for a way to express the relationship between those. I guess using
Requirements and Capabilities would be perfect but to my understanding you
can not use it for fragments.

On Wed, Jan 13, 2016 at 1:24 PM, CLEMENT Jean-Philippe <
jean-philippe.clem...@fr.thalesgroup.com> wrote:

> I'm not too sure what you need, but I would say first that you consider
> what you have (a text file) rather than what you need (a service or
> services). It seems you see things through the provider instead of the
> consumer.
>
> So, you have a button which calls a service S. Fine. Then you want S to be
> the best service. So you just have to implement a service S which is a
> proxy to T services and which will forward calls to the best T service.
>
> You can even reuse S instead of another T service. So, S is a proxy to
> other S services. The proxy has the better ranking in order the button to
> "find it". The proxy has to exclude itself from S service candidates.
>
> ...just a quick thought...
>
> JP
>
> [@@ OPEN @@]
>
> -Message d'origine-
> De : Milen Dyankov [mailto:milendyan...@gmail.com]
> Envoyé : mercredi 13 janvier 2016 11:10
> À : users@felix.apache.org
> Objet : Specifying dependency between a bundle and a fragment bundle
>
> Lets say I have a UI bundle that renders a button from template. The
> template is just a text file(s) inside UI bundle. Clicking the button calls
> a service (for the purpose of this example say one with the highest rank).
>
> The requirement is: change both the service that is called and the button
> in consistent manner.
>
> The first part is easy:
>  - To change the service one can simply provide a new bundle (call it S)
> containing the new service implementation (with higher rank or whatever
> else it takes to make it the one that service registry will give to the UI
> bundle).
>  - To change the button (or even replace it with something else) one can
> provide a fragment bundle (call it FB) with updated template file(s).
>
> The question is, how to keep those consistent? That is, make sure that
> either both S and FB are applied or none of them (lets assume S will
> somehow ensure the service is registered or stop itself if it can't do so)!
>
> It seams one needs to somehow declare a bidirectional dependency (I hate
> the way it sounds, but that's what it in fact is, isn't it) between a
> bundle and a fragment bundle. AFAIK this is not really possible as anything
> specified in fragment is applied to the host! Has anyone faced similar
> challenge before?
>
>
> --
> http://about.me/milen
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-- 
http://about.me/milen

Re: Bundle can't find its own classes: NoClassDefFoundError

2015-10-31 Thread Milen Dyankov

Thanks Richard,

oversimplifying the scenario and bringing it down to felix related parts,
what I did can be described as "build -> start felix -> demo something ->
stop felix -> build -> start felix > ..." loop! What I observed was ... hmm
I guess I should call it ... inconsistent behavior. Sometimes after restart
it will realize the bundles have changed and sometimes it will not. As I
wrote earlier this is my only case where I use pure felix. It is only for a
simple demo and I made it a habit to always clean the cache before starting
felix to avoid it. So this observation is an year old now and I don't
remember the details. It may be that it depends on what exactly changes in
the bundles or it may be me doing something wrong/stupid (the fact that I'm
used to use fileinstall normally, may have influenced my expectations). I
don't claim there is a bug in felix I was just sharing an observation. If I
find some time in the next few days I'll try to reproduce it and provide
more details.

Best,
Milen

On Fri, Oct 30, 2015 at 9:01 PM,  wrote:

> I'll take a look, thx!
> Citeren Raymond Auge :
>
>> It may serve you well to chose an alternative "osgi gradle plugin"
>> (perhaps
>> the official bnd gradle plugin [2]).
>>
>> Just sayin...
>> - Ray
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

-- 
http://about.me/milen

Re: Bundle can't find its own classes: NoClassDefFoundError

2015-10-30 Thread Milen Dyankov

This seems to happen with felix (version 4.6 in my case) from time to time.
Basically I have some symlinks in `felix/bundle` folder pointing to the jar
files generated by my IDE/build tool. Someties (haven't tried to figure out
why) it will not notice the JAR has changed and the only way to force it is
to clean the `felix/felix-cache`. As I'm only using plain felix for demo
purposes it is not a big deal for me (I always clean the cache) but I can
imagine how frustrating it would be if I was to build something serious
this way.

Best,
Milen



On Fri, Oct 30, 2015 at 8:21 PM, Richard S. Hall 
wrote:

> On 10/30/15 15:19 , i...@cuhka.com wrote:
>
>> Yes, indeed I'm using THE osgi plugin, and I didn't do any
>> Bundle-Classpath editing, nor did bnd. Anyway, after 'ctrl-alt-del' of my
>> Felix it all seems to be ok. While I still don't grasp while it occurs,
>> what can make it hapen, I can continue.
>>
>
> If I had to guess then, I'd say you somehow updated your bundle and got it
> in a strange state and didn't do a refresh of the framework after updating.
>
> -> richard
>
>
>
>> Maurice.
>> Citeren Paulo Renato de Athaydes :
>>
>> You should not mess with the Bundle-Classpath unless you know exactly
>>> what you're doing.
>>> Have a look at your bundle's Manifest, make sure the Bundle-ClassPath
>>> entry is not there, or if it is, it's just a dot.
>>> Otherwise you will get the kind of problem you're having.
>>> The osgi plugin (I assume you're using THE osgi plugin, I mean, the one
>>> called 'osgi') definitely won't magically add this to your Bundle.
>>> Renato
>>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


-- 
http://about.me/milen

Re: Core and Compendium APIS at runtime

2015-05-20 Thread Milen Dyankov

Thanks for your answer Richard!

I am aware if the FAQ however what it basically tells you is it depends
;) Thus I was hoping for some more insides so I can better understand the
intentions and the situation with service APIs from OSGi specs as of today.
So, if I understand your answer correctly the conclusions are:

- Never use compendium bundle at runtime because it is not a proper bundle
(whatever that means). I agree with you that this should be in FAQ at
least. It would be even better if there is some more official statement
(may be there is and I just couldn't find it) that also explains why!

- There are no proper/official separate API bundles for the service APIs
defined in the specs. Vendors are free to choose if they (1) package the
API in the implementation bundle, (2) provide the implementation only or
(3) provide separate bundles for API and implementation. Felix has chosen
the first approach to avoid maintaining too many bundles. IMHO
and according to the FAQ it seems the third approach makes more sense: *This
situation would be different if the service API were package in a separate
bundle. In this situation, all consumer bundles would be wired to the API
bundle, not to the provider bundle. Thus, if the provider were updated or
uninstalled and then refreshed, the consumer bundles would only be
minimally impacted (i.e., they would either switch to the new version of
the provider or to a different provider).* but I respect your decisions.

- There is no issue with split packages
http://wiki.osgi.org/wiki/Split_Packages because regardless of the
provider and the way APIs they are packaged/exported the API package(s)
*should* always be both complete and limited to what what OSGi alliance has
specified. IMHO this should be a bit more strict than just expecting
vendors to do it right. Then perhaps consumers can feel a bit more safe
from such issues when choosing an implementation (without the need to
examine it's internals). But I'm not going to argue about it.

Once again thanks for your answers. Please correct me if
I misunderstood something.

Regards,
Milen

On Sun, May 17, 2015 at 8:01 PM, Richard S. Hall he...@ungoverned.org
wrote:

On 5/17/15 12:57 , Milen Dyankov wrote:

Hi,

I recently stumbled upon something that makes me wonder about OSGI specs
APIs. As Metatype was the one API that made me start thinking about the
issue, I'll use it as an example but the question is about APIs in
general.

So while attempting to replace Felix's Metatype with Equinox one, I
realized Felix implementation jar provides also the API while Equinox does
not. So my first thought was that there should be another jar with the API
alone but I couldn't find one. Second thought was to install osgi.cmpn.jar
(it's a bundle after all) but I was told I should never do that and that
those jars are provided to be only used as compile time dependencies.

So here comes the question - who should provide the APIs at runtime for a
OSGI specs?

See the FAQ:

http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html#should-a-service-providerconsumer-bundle-be-packaged-with-its-service-api-packages

I would actually split the question into a few:
- is it really forbidden/nor recommended to use osgi.cmpn.jar at runtime?
If so can someone please elaborate?

This should probably be in the FAQ too. The compendium only happens to be
packaged as a bundle because that is how it is built, not because it
actually is a proper bundle. It is not cohesive, since it is just a
collection of API, and pulls in unnecessary dependencies. The OSGi Alliance
should probably quit publishing it as a bundle. Over the years, we seen
lots of users run into difficulties when using it as a bundle.

- shouldn't there be independent (perhaps released by OSGI alliance) API
bundles? If there should be but they are missing at the moment then why
Felix does not provide APIs in a separate bundles instead of packaging
them
with the implementation?

It's not really the purpose of the OSGi Alliance, but I suppose they
could. At Apache Felix, we have enough bundles to maintain, without
creating more.

- finally if the expectation is that each implementation provides also the
API isn't this leading to split package condition? I'm aware for most
specs
it probably makes no sense to have 2 different implementations at the same
time but still ...

No. How would they be split? Packages are self contained in OSGi bundles
unless you explicitly make them split. If done properly, there is little
harm in having multiple providers of a package. However, having a single
provider does provide some benefits too. As the FAQ says, it just depends
on your situation.

If you really are dealing with composing a system out of third-party
bundles, though, you cannot really always have it your way so you have to
deal with the realities on the ground.

- richard

I would appreciate

Re: Core and Compendium APIS at runtime

2015-05-20 Thread Milen Dyankov

Well I agree in general. My only point is that IMHO the one defining the
API should also be the one providing it at runtime. Since OSGi alliance is
defining a spec which describes a service API it should be the one
providing the API bundle. Vendors are still free to provide their own
implementations and extensions anyway they wish. But this way a random
consumer does not have to investigate if given vendor has included the API
in the implementation and if not then worry about which bundles need to be
installed at runtime to satisfy imports. I personally (as probably most
people on this list) can deal with it. And from that perspective it's easy
(and partly true) to say it's not rally a problem. However it doesn't look
nice and it does not help to fight the too complex and too messy
stereotypes.
Just my 2 cents!

Best,
Milen


On Wed, May 20, 2015 at 3:55 PM, Richard S. Hall he...@ungoverned.org
wrote:


 On 5/20/15 05:15 , Milen Dyankov wrote:

 Thanks for your answer Richard!

 I am aware if the FAQ however what it basically tells you is it depends
 ;)


 Unfortunately, it does depend on your circumstances. There are very few
 cases in software engineering where you can say, always do it like
 this...that's the way the cookie crumbles.

  Thus I was hoping for some more insides so I can better understand the
 intentions and the situation with service APIs from OSGi specs as of
 today.
 So, if I understand your answer correctly the conclusions are:

 - Never use compendium bundle at runtime because it is not a proper bundle
 (whatever that means).


 Bundles (i.e., modules) are supposed to be cohesive and loosely coupled.
 The compendium is just a bunch of APIs thrown into a JAR file, so that
 hardly is cohesive and certainly wouldn't lead to low coupling. Understand?

I agree with you that this should be in FAQ at
 least. It would be even better if there is some more official statement
 (may be there is and I just couldn't find it) that also explains why!

 - There are no proper/official separate API bundles for the service APIs
 defined in the specs. Vendors are free to choose if they (1) package the
 API in the implementation bundle, (2) provide the implementation only or
 (3) provide separate bundles for API and implementation. Felix has chosen
 the first approach to avoid maintaining too many bundles.


 No choice has been made at Apache Felix, but generally people have
 gravitated to that approach. Subprojects are free to do it any way they
 want, because use cases vary.

IMHO
 and according to the FAQ it seems the third approach makes more sense:
 *This
 situation would be different if the service API were package in a separate
 bundle. In this situation, all consumer bundles would be wired to the API
 bundle, not to the provider bundle. Thus, if the provider were updated or
 uninstalled and then refreshed, the consumer bundles would only be
 minimally impacted (i.e., they would either switch to the new version of
 the provider or to a different provider).*  but I respect your decisions.


 It does make a lot of sense in many cases. If you are unsure of your
 needs, I'd recommend this as the default approach.


 - There is no issue with split packages
 http://wiki.osgi.org/wiki/Split_Packages  because regardless of the
 provider and the way APIs they are packaged/exported the API package(s)
 *should* always be both complete and limited to what what OSGi alliance
 has
 specified. IMHO this should be a bit more strict than just expecting
 vendors to do it right. Then perhaps consumers can feel a bit more safe
 from such issues when choosing an implementation (without the need to
 examine it's internals). But I'm not going to argue about it.


 There is not much that can be done about this. What do you want the OSGi
 Alliance to do? We could require that ever developer give a signed list of
 every class that should be in every package and store that in some central
 repository. Then any time a bundle says they export a particular class, the
 framework could go out to that authority get the list of classes for that
 package and scan the bundle to make sure it contains the proper classes. Of
 course, this wouldn't even guarantee anything, since the bundle could
 include bogus implementation classes. Nor could you make it better by
 including class signatures in this central repository, because that would
 eliminate substitutability of different provider implementations.

 At some point, you just have to trust the bundle developers and if they
 end up lying, the you put that bundle developer on your blacklist and you
 exclude them in your future choices.

 As with everything, you're not going to get something (worthwhile) for
 free.

 - richard



 Once again thanks for your answers. Please correct me if
 I misunderstood something.

 Regards,
 Milen





 On Sun, May 17, 2015 at 8:01 PM, Richard S. Hallhe...@ungoverned.org
 wrote:

  On 5/17/15 12:57 , Milen Dyankov wrote:

  Hi,

 I recently

Re: Core and Compendium APIS at runtime

2015-05-20 Thread Milen Dyankov


 Now, if you are saying that the framework should somehow enforce that
 implementations never provide the service API and that only the official
 service API bundles can be used to provide those packages, then I'd say
 that this would go too far.


No I didn't meant to say that. Rather that implementations would not
have/need to do it. At least I for one can not see a good reason why would
someone want to provide the same version of someone else's API if
it's already publicly available.



On Wed, May 20, 2015 at 5:47 PM, Richard S. Hall he...@ungoverned.org
wrote:

 On 5/20/15 11:37 , Milen Dyankov wrote:

 Well I agree in general. My only point is that IMHO the one defining the
 API should also be the one providing it at runtime. Since OSGi alliance is
 defining a spec which describes a service API it should be the one
 providing the API bundle.


 And apparently the OSGi Alliance will do so from now on; however, ...

  Vendors are still free to provide their own
 implementations and extensions anyway they wish. But this way a random
 consumer does not have to investigate if given vendor has included the API
 in the implementation and if not then worry about which bundles need to be
 installed at runtime to satisfy imports.


 You will still not be relieved of performing this task since bundles may
 or may not come packaged with the APIs, so you'll still likely need to
 understand this, because multiple providers can (and do) lead to unexpected
 wiring when you are assuming there is only one provider.

 Now, if you are saying that the framework should somehow enforce that
 implementations never provide the service API and that only the official
 service API bundles can be used to provide those packages, then I'd say
 that this would go too far.

  I personally (as probably most
 people on this list) can deal with it. And from that perspective it's easy
 (and partly true) to say it's not rally a problem. However it doesn't look
 nice and it does not help to fight the too complex and too messy
 stereotypes.
 Just my 2 cents!


 Understood, but clamping things downs just leads to other messiness (see
 .NET and its strong versions).

 As I said before, there is no free lunch. Developing software is
 complicated and you have to work hard to keep it from getting messy.

 - richard



 Best,
 Milen


 On Wed, May 20, 2015 at 3:55 PM, Richard S. Hall he...@ungoverned.org
 wrote:

  On 5/20/15 05:15 , Milen Dyankov wrote:

  Thanks for your answer Richard!

 I am aware if the FAQ however what it basically tells you is it
 depends
 ;)

  Unfortunately, it does depend on your circumstances. There are very few
 cases in software engineering where you can say, always do it like
 this...that's the way the cookie crumbles.

   Thus I was hoping for some more insides so I can better understand the

 intentions and the situation with service APIs from OSGi specs as of
 today.
 So, if I understand your answer correctly the conclusions are:

 - Never use compendium bundle at runtime because it is not a proper
 bundle
 (whatever that means).

  Bundles (i.e., modules) are supposed to be cohesive and loosely
 coupled.
 The compendium is just a bunch of APIs thrown into a JAR file, so that
 hardly is cohesive and certainly wouldn't lead to low coupling.
 Understand?

 I agree with you that this should be in FAQ at

 least. It would be even better if there is some more official statement
 (may be there is and I just couldn't find it) that also explains why!

 - There are no proper/official separate API bundles for the service APIs
 defined in the specs. Vendors are free to choose if they (1) package the
 API in the implementation bundle, (2) provide the implementation only or
 (3) provide separate bundles for API and implementation. Felix has
 chosen
 the first approach to avoid maintaining too many bundles.

  No choice has been made at Apache Felix, but generally people have
 gravitated to that approach. Subprojects are free to do it any way they
 want, because use cases vary.

 IMHO

 and according to the FAQ it seems the third approach makes more sense:
 *This
 situation would be different if the service API were package in a
 separate
 bundle. In this situation, all consumer bundles would be wired to the
 API
 bundle, not to the provider bundle. Thus, if the provider were updated
 or
 uninstalled and then refreshed, the consumer bundles would only be
 minimally impacted (i.e., they would either switch to the new version of
 the provider or to a different provider).*  but I respect your
 decisions.

  It does make a lot of sense in many cases. If you are unsure of your
 needs, I'd recommend this as the default approach.


  - There is no issue with split packages
 http://wiki.osgi.org/wiki/Split_Packages  because regardless of the
 provider and the way APIs they are packaged/exported the API package(s)
 *should* always be both complete and limited to what what OSGi alliance
 has
 specified. IMHO this should

Core and Compendium APIS at runtime

2015-05-17 Thread Milen Dyankov

Hi,

I recently stumbled upon something that makes me wonder about OSGI specs
APIs. As Metatype was the one API that made me start thinking about the
issue, I'll use it as an example but the question is about APIs in general.

So while attempting to replace Felix's Metatype with Equinox one,  I
realized Felix implementation jar provides also the API while Equinox does
not. So my first thought was that there should be another jar with the API
alone but I couldn't find one. Second thought was to install osgi.cmpn.jar
(it's  a bundle after all) but I was told I should never do that and that
those jars are provided to be only used as compile time dependencies.

So here comes the question - who should provide the APIs at runtime for a
OSGI specs?
I would actually split the question into a few:
- is it really forbidden/nor recommended to use osgi.cmpn.jar at runtime?
If so can someone please elaborate?
- shouldn't there be independent  (perhaps released by OSGI alliance) API
bundles? If there should be but they are missing at the moment then why
Felix does not provide APIs in a separate bundles instead of packaging them
with the implementation?
- finally if the expectation is that each implementation provides also the
API isn't this leading to split package condition? I'm aware for most specs
it probably makes no sense to have 2 different implementations at the same
time but still ...

I would appreciate if someone can throw more light on the subject.

Regards,
Milen

Re: OSGi Declarative Services dependency on a generic supertype

2015-02-06 Thread Milen Dyankov

You are right! My bad! I should have called the interface '
AVerySpecificButtonThatCanOnlyBeUsedWithThisParticularUsecase' ;)
Luckily Java allows you to make use of more than one interface in your
application so all the other valid reasons can be covered too ;)





On Thu, Feb 5, 2015 at 10:04 PM, Ferry Huberts maili...@hupie.com wrote:



 On 05/02/15 21:21, Milen Dyankov wrote:

 Agree to some extend. However here is what I meant with a stupid example.
 Say I have GUI where I can dynamically add buttons to perform operations
 on
 something. If I could do

 @AutoRegisterComponentsFromClassesImplementingMe
 public interface Button {
void performActionOn (Something something);
 }

 public abstract class AbstractButton implements Button {
 // some common logic here
 }

 then I could say to my not-so-keen-about-osgi colleagues You know what,
 just extend the AbstractButton, add your logic, build (tooling will make
 it
 a bundle), deploy and your button will appear in the UI! Again it's NOT
 that there is some crucial missing feature in OSGi / DS but rather a
 matter
 of convenience!


 And why is that adding just one tiny step ('put @Component on your class')
 is too difficult?

 Besides, there are many valid reasons for implementing an interface and
 _not_ exposing it as a service, also for your button case.


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




-- 
http://about.me/milen

Re: OSGi Declarative Services dependency on a generic supertype

2015-02-06 Thread Milen Dyankov

Understood! As I said it's not that it's something crucial missing! However
at least some alternative to iPOJO's @Stereotype would be nice.

On Thu, Feb 5, 2015 at 10:03 PM, David Jencks 
david_jen...@yahoo.com.invalid wrote:

 One of the principles we've tried to keep to in DS is that all the
 information about what to do is in the xml descriptor and we don't do
 significant runtime analysis of capabilities and we definitely don't do
 runtime class scanning.  So it sounds like you are proposing a tectonic
 shift in the philosophy behind DS which is unlikely to happen any time
 soon.  Having dealt with annotation processing for javaee I cannot express
 how strongly I am against runtime annotation processing for DS.

 thanks
 david jencks

 On Feb 5, 2015, at 3:41 PM, Milen Dyankov milendyan...@gmail.com wrote:

  So as I mentioned earlier you have 2 options:
 
  (a) build time - which is exactly how @Component annotations are
 processed.
  Basically treat every class implementing the interface as if it was
  annotated with @Component and @Service
 
  (b) deploy / run time - which is more or less what you suggest although I
  can imagine different implementations
 
  So I fully agree with you that it can be done. But in the context set by
  the original question:
 
  - Is this possible with DS as of now - AFAIK no
  - is it something that DS/SCR should support - I don't know. I think it
  could, but again there may be implications I'm not aware of.
 
 
 
 
 
 
  On Thu, Feb 5, 2015 at 9:29 PM, David Jencks
 david_jen...@yahoo.com.invalid
  wrote:
 
  I still don't understand in your example what is supposed to create an
  instance of your button class.
 
  I think it's pretty odd, but I think with my proposal for extension
  annotation processors for DS and metatype annotation processing  in
 bnd, if
  you were willing to use DS and mark the button class you actually want
 to
  be a real live button with @Component so DS knows enough to create one,
 you
  could write an extension processor that would find your @AutoRegister
  annotation on the interface in the inheritance hierarchy and add it to
 the
  exposed services.
 
  thanks
  david jencks
 
  On Feb 5, 2015, at 3:21 PM, Milen Dyankov milendyan...@gmail.com
 wrote:
 
  Agree to some extend. However here is what I meant with a stupid
 example.
  Say I have GUI where I can dynamically add buttons to perform
 operations
  on
  something. If I could do
 
  @AutoRegisterComponentsFromClassesImplementingMe
  public interface Button {
  void performActionOn (Something something);
  }
 
  public abstract class AbstractButton implements Button {
   // some common logic here
  }
 
  then I could say to my not-so-keen-about-osgi colleagues You know
 what,
  just extend the AbstractButton, add your logic, build (tooling will
 make
  it
  a bundle), deploy and your button will appear in the UI! Again it's
 NOT
  that there is some crucial missing feature in OSGi / DS but rather a
  matter
  of convenience!
 
 
 
 
  On Thu, Feb 5, 2015 at 8:46 PM, David Jencks
  david_jen...@yahoo.com.invalid
  wrote:
 
  With DS and the spec annotations, if your component class directly
  implements the interface, it will be registered as a service exposing
  that
  interface.
 
  If your class is not a DS component, I'm not sure what you expect to
  create an instance of your class in order to register it as a
  service..  I
  guess you could register a byte-code weaver that looked for classes
  implementing your interface of interest, and added byte code that got
  the
  bundle context from the class loader, and registered the instance in
 the
  service registry, but I don't think you would actually find that very
  useful as there would be no way to specify service properties in order
  to
  distinguish different instances.  It would certainly interfere with
 any
  existing component model such as DS or blueprint and probably with any
  attempt to register a service in code.
 
  david jencks
 
  On Feb 5, 2015, at 2:37 PM, Milen Dyankov milendyan...@gmail.com
  wrote:
 
  I may be interpreting Pawel's case wrong but I also have had
 situations
  in
  the past where I wish I was able to somehow mark a interface (by
 using
  annotation for example) and basically say whoever implements that
  interface should be automatically registered as a service! AFAIK
 that
  is
  not possible with SCR/DS although it may be very convenient in some
  cases.
 
  Now if such feature was to be implemented the question is weather it
  should
  happen at run/deploy time (probably expensive) or build time (rather
 a
  matter of tooling and not strictly related to DS). However there may
  also
  be some side effects I have not thought about and perhaps a good
 reason
  not
  to have it.
 
  Just my 2 cents
 
  Best,
  Milen
 
  On Thu, Feb 5, 2015 at 8:15 PM, David Jencks
  david_jen...@yahoo.com.invalid
  wrote:
 
  The default for scr annotations is to expose all the directly
  implemented

Re: OSGi Declarative Services dependency on a generic supertype

2015-02-05 Thread Milen Dyankov

I may be interpreting Pawel's case wrong but I also have had situations in
the past where I wish I was able to somehow mark a interface (by using
annotation for example) and basically say whoever implements that
interface should be automatically registered as a service! AFAIK that is
not possible with SCR/DS although it may be very convenient in some cases.

Now if such feature was to be implemented the question is weather it should
happen at run/deploy time (probably expensive) or build time (rather a
matter of tooling and not strictly related to DS). However there may also
be some side effects I have not thought about and perhaps a good reason not
to have it.

Just my 2 cents

Best,
Milen

On Thu, Feb 5, 2015 at 8:15 PM, David Jencks david_jen...@yahoo.com.invalid
 wrote:

 The default for scr annotations is to expose all the directly implemented
 interfaces.  If you want something else you can explicitly list the classes
 to expose in the @Component annotation.. This is really easy to understand
 from the class itself.  You can re-list an interface implemented by a
 superclass or that is a super-interface of a directly implemented interface
 if you want, that won't hurt your class.  Your proposal of all
 bundle-exported interfaces seems really restrictive and odd to me, any
 directly implemented interface from another bundle (say from a spec) would
 force you to not use the default.  To understand what the component exposes
 you would also have to try to figure out what the bundle exports, which is
 not obvious from the component class itself.

 thanks
 david jencks

 On Feb 5, 2015, at 1:06 PM, Pawel Pogorzelski 
 pawel.pogorzels...@gmail.com wrote:

  Alright, thanks Neil. I can see can see some corner cases where this
  behavior could would be desired. It's just the default that bothers me -
 I
  think by default a service should be registered under all the
  bundle-exported interfaces. After all, if you want to hide implementation
  you do it differently - by defining a public interface and hiding the
 rest
  in private packages. The same with lookups - if you want to get a
 specific
  instance then OSGi filters is the way to go. So, if you're relaying on
 not
  registering under all interfaces probably means there's something wrong
 in
  your design or the container you run in.
 
  Paweł
 
  On Thu, Feb 5, 2015 at 5:37 PM, Neil Bartlett njbartl...@gmail.com
 wrote:
 
  Services in OSGi are intended so that you can implement many interfaces
  but publish under a subset. Therefore the set of published services
 must be
  listed explicitly.
 
  Neil
 
 
  On Thursday, 5 February 2015 at 16:15, Pawel Pogorzelski wrote:
 
  Thanks Ferry, it indeed works. Is there any way of doing it without
  specifying all the object supertypes during the registration? Maybe
 using
  Felix SCR annotations instead of OSGi ones?
 
  Cheers,
  Pawel
 
 
 
  On Thu, Feb 5, 2015 at 5:02 PM, Ferry Huberts maili...@hupie.com
  wrote:
 
 
 
  On 05/02/15 16:59, Pawel Pogorzelski wrote:
 
  Guys,
  I have a generic interface IRepositoryT extended by
  IAppleRepository,
  IOrangeRepository and so on. Concrete implementations like
  AppleRepository
  are registered in the container with non-generic interfaces like
  IAppleRepository. Is it possible to tell DS engine I need every
  service
  sublassing IRepository? Corresponding line in my component.xml looks
  like
  follows:
 
  reference name=Repository cardinality=0..n policy=dynamic
  interface=com.Whatever.IRepository bind=addRepository
  unbind=removeRepository/
 
  but it doesn't work. I'm on Felix 4.4.1.
 
 
  Then the bundles don't advertise the IRepository interface but their
  subclass(es).
 
  Make the bundles advertise IRepository and it'll work.
 
  -
  To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
  For additional commands, e-mail: users-h...@felix.apache.org
 
 
 
 
 
 
 


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




-- 
http://about.me/milen

Re: OSGi Declarative Services dependency on a generic supertype

2015-02-05 Thread Milen Dyankov

Agree to some extend. However here is what I meant with a stupid example.
Say I have GUI where I can dynamically add buttons to perform operations on
something. If I could do

@AutoRegisterComponentsFromClassesImplementingMe
public interface Button {
  void performActionOn (Something something);
}

public abstract class AbstractButton implements Button {
   // some common logic here
}

then I could say to my not-so-keen-about-osgi colleagues You know what,
just extend the AbstractButton, add your logic, build (tooling will make it
a bundle), deploy and your button will appear in the UI! Again it's NOT
that there is some crucial missing feature in OSGi / DS but rather a matter
of convenience!




On Thu, Feb 5, 2015 at 8:46 PM, David Jencks david_jen...@yahoo.com.invalid
 wrote:

 With DS and the spec annotations, if your component class directly
 implements the interface, it will be registered as a service exposing that
 interface.

 If your class is not a DS component, I'm not sure what you expect to
 create an instance of your class in order to register it as a service..  I
 guess you could register a byte-code weaver that looked for classes
 implementing your interface of interest, and added byte code that got the
 bundle context from the class loader, and registered the instance in the
 service registry, but I don't think you would actually find that very
 useful as there would be no way to specify service properties in order to
 distinguish different instances.  It would certainly interfere with any
 existing component model such as DS or blueprint and probably with any
 attempt to register a service in code.

 david jencks

 On Feb 5, 2015, at 2:37 PM, Milen Dyankov milendyan...@gmail.com wrote:

  I may be interpreting Pawel's case wrong but I also have had situations
 in
  the past where I wish I was able to somehow mark a interface (by using
  annotation for example) and basically say whoever implements that
  interface should be automatically registered as a service! AFAIK that is
  not possible with SCR/DS although it may be very convenient in some
 cases.
 
  Now if such feature was to be implemented the question is weather it
 should
  happen at run/deploy time (probably expensive) or build time (rather a
  matter of tooling and not strictly related to DS). However there may also
  be some side effects I have not thought about and perhaps a good reason
 not
  to have it.
 
  Just my 2 cents
 
  Best,
  Milen
 
  On Thu, Feb 5, 2015 at 8:15 PM, David Jencks
 david_jen...@yahoo.com.invalid
  wrote:
 
  The default for scr annotations is to expose all the directly
 implemented
  interfaces.  If you want something else you can explicitly list the
 classes
  to expose in the @Component annotation.. This is really easy to
 understand
  from the class itself.  You can re-list an interface implemented by a
  superclass or that is a super-interface of a directly implemented
 interface
  if you want, that won't hurt your class.  Your proposal of all
  bundle-exported interfaces seems really restrictive and odd to me, any
  directly implemented interface from another bundle (say from a spec)
 would
  force you to not use the default.  To understand what the component
 exposes
  you would also have to try to figure out what the bundle exports, which
 is
  not obvious from the component class itself.
 
  thanks
  david jencks
 
  On Feb 5, 2015, at 1:06 PM, Pawel Pogorzelski 
  pawel.pogorzels...@gmail.com wrote:
 
  Alright, thanks Neil. I can see can see some corner cases where this
  behavior could would be desired. It's just the default that bothers me
 -
  I
  think by default a service should be registered under all the
  bundle-exported interfaces. After all, if you want to hide
 implementation
  you do it differently - by defining a public interface and hiding the
  rest
  in private packages. The same with lookups - if you want to get a
  specific
  instance then OSGi filters is the way to go. So, if you're relaying on
  not
  registering under all interfaces probably means there's something wrong
  in
  your design or the container you run in.
 
  Paweł
 
  On Thu, Feb 5, 2015 at 5:37 PM, Neil Bartlett njbartl...@gmail.com
  wrote:
 
  Services in OSGi are intended so that you can implement many
 interfaces
  but publish under a subset. Therefore the set of published services
  must be
  listed explicitly.
 
  Neil
 
 
  On Thursday, 5 February 2015 at 16:15, Pawel Pogorzelski wrote:
 
  Thanks Ferry, it indeed works. Is there any way of doing it without
  specifying all the object supertypes during the registration? Maybe
  using
  Felix SCR annotations instead of OSGi ones?
 
  Cheers,
  Pawel
 
 
 
  On Thu, Feb 5, 2015 at 5:02 PM, Ferry Huberts maili...@hupie.com
  wrote:
 
 
 
  On 05/02/15 16:59, Pawel Pogorzelski wrote:
 
  Guys,
  I have a generic interface IRepositoryT extended by
  IAppleRepository,
  IOrangeRepository and so on. Concrete implementations like
  AppleRepository

Re: OSGi Declarative Services dependency on a generic supertype

2015-02-05 Thread Milen Dyankov

So as I mentioned earlier you have 2 options:

(a) build time - which is exactly how @Component annotations are processed.
Basically treat every class implementing the interface as if it was
annotated with @Component and @Service

(b) deploy / run time - which is more or less what you suggest although I
can imagine different implementations

So I fully agree with you that it can be done. But in the context set by
the original question:

- Is this possible with DS as of now - AFAIK no
- is it something that DS/SCR should support - I don't know. I think it
could, but again there may be implications I'm not aware of.






On Thu, Feb 5, 2015 at 9:29 PM, David Jencks david_jen...@yahoo.com.invalid
 wrote:

 I still don't understand in your example what is supposed to create an
 instance of your button class.

 I think it's pretty odd, but I think with my proposal for extension
 annotation processors for DS and metatype annotation processing  in bnd, if
 you were willing to use DS and mark the button class you actually want to
 be a real live button with @Component so DS knows enough to create one, you
 could write an extension processor that would find your @AutoRegister
 annotation on the interface in the inheritance hierarchy and add it to the
 exposed services.

 thanks
 david jencks

 On Feb 5, 2015, at 3:21 PM, Milen Dyankov milendyan...@gmail.com wrote:

  Agree to some extend. However here is what I meant with a stupid example.
  Say I have GUI where I can dynamically add buttons to perform operations
 on
  something. If I could do
 
  @AutoRegisterComponentsFromClassesImplementingMe
  public interface Button {
   void performActionOn (Something something);
  }
 
  public abstract class AbstractButton implements Button {
// some common logic here
  }
 
  then I could say to my not-so-keen-about-osgi colleagues You know what,
  just extend the AbstractButton, add your logic, build (tooling will make
 it
  a bundle), deploy and your button will appear in the UI! Again it's NOT
  that there is some crucial missing feature in OSGi / DS but rather a
 matter
  of convenience!
 
 
 
 
  On Thu, Feb 5, 2015 at 8:46 PM, David Jencks
 david_jen...@yahoo.com.invalid
  wrote:
 
  With DS and the spec annotations, if your component class directly
  implements the interface, it will be registered as a service exposing
 that
  interface.
 
  If your class is not a DS component, I'm not sure what you expect to
  create an instance of your class in order to register it as a
 service..  I
  guess you could register a byte-code weaver that looked for classes
  implementing your interface of interest, and added byte code that got
 the
  bundle context from the class loader, and registered the instance in the
  service registry, but I don't think you would actually find that very
  useful as there would be no way to specify service properties in order
 to
  distinguish different instances.  It would certainly interfere with any
  existing component model such as DS or blueprint and probably with any
  attempt to register a service in code.
 
  david jencks
 
  On Feb 5, 2015, at 2:37 PM, Milen Dyankov milendyan...@gmail.com
 wrote:
 
  I may be interpreting Pawel's case wrong but I also have had situations
  in
  the past where I wish I was able to somehow mark a interface (by using
  annotation for example) and basically say whoever implements that
  interface should be automatically registered as a service! AFAIK that
 is
  not possible with SCR/DS although it may be very convenient in some
  cases.
 
  Now if such feature was to be implemented the question is weather it
  should
  happen at run/deploy time (probably expensive) or build time (rather a
  matter of tooling and not strictly related to DS). However there may
 also
  be some side effects I have not thought about and perhaps a good reason
  not
  to have it.
 
  Just my 2 cents
 
  Best,
  Milen
 
  On Thu, Feb 5, 2015 at 8:15 PM, David Jencks
  david_jen...@yahoo.com.invalid
  wrote:
 
  The default for scr annotations is to expose all the directly
  implemented
  interfaces.  If you want something else you can explicitly list the
  classes
  to expose in the @Component annotation.. This is really easy to
  understand
  from the class itself.  You can re-list an interface implemented by a
  superclass or that is a super-interface of a directly implemented
  interface
  if you want, that won't hurt your class.  Your proposal of all
  bundle-exported interfaces seems really restrictive and odd to me,
 any
  directly implemented interface from another bundle (say from a spec)
  would
  force you to not use the default.  To understand what the component
  exposes
  you would also have to try to figure out what the bundle exports,
 which
  is
  not obvious from the component class itself.
 
  thanks
  david jencks
 
  On Feb 5, 2015, at 1:06 PM, Pawel Pogorzelski 
  pawel.pogorzels...@gmail.com wrote:
 
  Alright, thanks Neil. I can see can see some corner

Re: Getting a reference to a declarative service

2015-01-20 Thread Milen Dyankov

Also make sure that apart from generating the descriptor(s) it adds the
correct 'Service-Component' header in your manifest. I recall some problems
when both 'maven-bundle-plugin' and 'maven-scr-plugin' are used together. I
personally try to avoid using 'maven-scr-plugin' and add
'_dsannotations*/_dsannotations' to 'maven-bundle-plugin' configuration
instead!

Best,
Milen

On Tue, Jan 20, 2015 at 1:19 PM, Neil Bartlett njbartl...@gmail.com wrote:

 Dirk: I don’t think Artem was asking about activation of the component, he
 has a problem with service registration. So whether the component is
 immediate or delayed seems to be irrelevant.

 Artem: there are a few things you need to check. Is your bundle active? Do
 you have a DS implementation bundle (such as org.apache.felix.scr, or
 org.eclipse.equinox.ds) installed and active?

 Regards,
 Neil


  On 20 Jan 2015, at 11:09, Dirk Rudolph dirk.rudo...@netcentric.biz
 wrote:
 
  Try to add immediate=“true” to your component definition. This should
 result in something like
 
  ?xml version=1.0 encoding=UTF-8?components xmlns:scr=
 http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component immediate=“true”
 name=ru.multicabinet.gateway.ExampleDS
implementation class=ru.multicabinet.gateway.ExampleDS/
service servicefactory=false
provide interface=ru.multicabinet.gateway.SimpleI/
/service
property name=service.pid
 value=ru.multicabinet.gateway.ExampleDS/
/scr:component
  /components
 
  and causes the component to be started immediately after it has been
 registered.
 
  Kind regards,
  Dirk Rudolph | Senior Software Engineer
 
  Netcentric AG
 
  M: +41 79 642 37 11
  D: +49 174 966 84 34
 
  dirk.rudo...@netcentric.biz mailto:dirk.rudo...@netcentric.biz |
 www.netcentric.biz http://www.netcentric.biz/
  On 20 Jan 2015, at 11:53, Artem Zhirkov a...@develdynamic.com wrote:
 
  Hello,
 
  I want to include more than one service into a bundle, so it seems like
 I have to make a use of declarative services.
 
  I'm building a test bundle with maven + maven-bundle-plugin and
 generating the ds descriptor with maven-scr-plugin, so it looks like this:
 
  ?xml version=1.0 encoding=UTF-8?components xmlns:scr=
 http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component name=ru.multicabinet.gateway.ExampleDS
implementation class=ru.multicabinet.gateway.ExampleDS/
service servicefactory=false
provide interface=ru.multicabinet.gateway.SimpleI/
/service
property name=service.pid
 value=ru.multicabinet.gateway.ExampleDS/
/scr:component
  /components
 
  After installing the test bundle into my osgi container I'm trying to
 get a list of all services in the test bundle by calling
 bundle.getRegisteredServices(), but it'd always return null.
 
  What I'm doing wrong? Maybe  I should use ServiceTracker to obtain a
 reference to ds service?
 
  Thanks
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
  For additional commands, e-mail: users-h...@felix.apache.org
 
 


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




-- 
http://about.me/milen

Re: Datasource with Apache Felix.

2014-12-17 Thread Milen Dyankov

You probably know this but just to make it clear - Karaf is not directly
comparable with Felix. It can use Felix or Equinox but it comes OOTB with
many bundles pre-installed. That is why your datasource works in Karaf.
It will work in Felix if you have appropriate bundles (that understand what
datasource is, how is defined and how to deal with it) installed. In your
case this is first the blueprint impl to process your blueprint config.
Then it depend on what really a 'datasource' is in your case you'll need
some more. Have a look at
https://repo1.maven.org/maven2/org/apache/karaf/features/enterprise/3.0.2/enterprise-3.0.2-features.xml
to see what Karaf uses if you want to stick with those implementations.
There you'll see a jdbc, jpa, ... features and what bundles they
consists of. Depending on what exactly is your use case, you may or may not
need to install all of them!

Best,
Milen

On Wed, Dec 17, 2014 at 2:05 PM, Achim Nierbeck bcanh...@googlemail.com
wrote:

No I'm not saying that,
but if he expects to use blueprint xml definitions for a datasource he'll
need to put all those bundles back in again, in
the end he might end up with the Karaf-minimal distro so where is the
point?

regards, Achim

2014-12-17 14:02 GMT+01:00 Neil Bartlett njbartl...@gmail.com:

Achim, are you seriously saying that you need the complete Karaf stack
just in order to use a datasource?? That’s nuts.

RamaKrishna, what is the issue you’re having? If you have a datasource
bundle you can just install it in Felix and it will work. If not, please
report the errors you get.

Regards,
Neil

On 17 Dec 2014, at 12:51, Achim Nierbeck bcanh...@googlemail.com
wrote:

Any reason not to stick to Karaf as your container as it uses Felix as
its
framework?
Otherwise you'll need to re-assemble the complete stack that is used
inside
Karaf.
So you'll need to add the blueprint bundles first, those can be found
at
the Aries Project.
Now you'll need to make sure you have Felix File install configured
correctly and installed with your framework.
For that you'll need some sort of main that does the bootstrapping of
bundles that need to be part of the basic setup.
...
I think I could go on for about 4 to 5 other projects you most likely
would
need.
Again, why don't you stick to Karaf as it brings all of this
infrastructural glueing?

regards, Achim

2014-12-17 12:13 GMT+01:00 Ramakrishna R ramakrishna...@gmail.com:

Team,

I want to know how to configure datasource in Felix container. I have
a
blueprint that contains datasource info, this i want to make work in
Felix.
In Karaf when i put it in deploy folder it works perfectly. Am not
getting
a direction as how to achive this in felix.

--
Cheers

RamaKrishna RV

Apache Member
Apache Karaf http://karaf.apache.org/ Committer PMC
OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/
Committer

Project Lead
blog http://notizblog.nierbeck.de/
Co-Author of Apache Karaf Cookbook http://bit.ly/1ps9rkS

Software Architect / Project Manager / Scrum Master

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

Apache Member
Apache Karaf http://karaf.apache.org/ Committer PMC
OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer
Project Lead
blog http://notizblog.nierbeck.de/
Co-Author of Apache Karaf Cookbook http://bit.ly/1ps9rkS

Software Architect / Project Manager / Scrum Master

--
http://about.me/milen

Re: Datasource with Apache Felix.

2014-12-17 Thread Milen Dyankov

Well if someone says he wants to use B instead of A, I assume he/she has
his reasons. That's why I tend to avoid answering like just stay with A
as it doesn't really help. Besides, you don't really need everything Karaf
comes with, in order to define and use datasources. Depends on the use case
one may end up anywhere between installing 2-3 bundles to building custom
Karaf.

Best,
Milen

On Wed, Dec 17, 2014 at 2:46 PM, Jean-Baptiste Onofré j...@nanthrax.net
wrote:

 Hi guys,

 if at the end, you install the same bundles as in Karaf (where we also
 bring some configuration and convenient commands), the question is why not
 directly using Karaf ;)

 Regards
 JB


 On 12/17/2014 02:44 PM, Milen Dyankov wrote:

 You probably know this but just to make it clear - Karaf is not directly
 comparable with Felix. It can use Felix or Equinox but it comes OOTB with
 many bundles pre-installed. That is why your datasource works in Karaf.
 It will work in Felix if you have appropriate bundles (that understand
 what
 datasource is, how is defined and how to deal with it) installed. In your
 case this is first the blueprint impl to process your blueprint config.
 Then it depend on what really a 'datasource' is in your case you'll need
 some more. Have a look at
 https://repo1.maven.org/maven2/org/apache/karaf/
 features/enterprise/3.0.2/enterprise-3.0.2-features.xml
 to see what Karaf uses if you want to stick with those implementations.
 There you'll see a jdbc, jpa, ... features and what bundles they
 consists of. Depending on what exactly is your use case, you may or may
 not
 need to install all of them!

 Best,
 Milen


 On Wed, Dec 17, 2014 at 2:05 PM, Achim Nierbeck bcanh...@googlemail.com
 wrote:


 No I'm not saying that,
 but if he expects to use blueprint xml definitions for a datasource he'll
 need to put all those bundles back in again, in
 the end he might end up with the Karaf-minimal distro so where is the
 point?

 regards, Achim

 2014-12-17 14:02 GMT+01:00 Neil Bartlett njbartl...@gmail.com:


 Achim, are you seriously saying that you need the complete Karaf stack
 just in order to use a datasource?? That’s nuts.

 RamaKrishna, what is the issue you’re having? If you have a datasource
 bundle you can just install it in Felix and it will work. If not, please
 report the errors you get.

 Regards,
 Neil

  On 17 Dec 2014, at 12:51, Achim Nierbeck bcanh...@googlemail.com

 wrote:


 Any reason not to stick to Karaf as your container as it uses Felix as

 its

 framework?
 Otherwise you'll need to re-assemble the complete stack that is used

 inside

 Karaf.
 So you'll need to add the blueprint bundles first, those can be found

 at

 the Aries Project.
 Now you'll need to make sure you have Felix File install configured
 correctly and installed with your framework.
 For that you'll need some sort of main that does the bootstrapping of
 bundles that need to be part of the basic setup.
 ...
 I think I could go on for about 4 to 5 other projects you most likely

 would

 need.
 Again, why don't you stick to Karaf as it brings all of this
 infrastructural glueing?

 regards, Achim

 2014-12-17 12:13 GMT+01:00 Ramakrishna R ramakrishna...@gmail.com:


 Team,

 I want to know how to configure datasource in Felix container. I have

 a

 blueprint that contains datasource info, this i want to make work in

 Felix.

 In Karaf when i put it in deploy folder it works perfectly. Am not

 getting

 a direction as how to achive this in felix.

 --
 Cheers

 RamaKrishna RV



 --

 Apache Member
 Apache Karaf http://karaf.apache.org/ Committer  PMC
 OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/

 Committer

 

 Project Lead
 blog http://notizblog.nierbeck.de/
 Co-Author of Apache Karaf Cookbook http://bit.ly/1ps9rkS

 Software Architect / Project Manager / Scrum Master



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



 --

 Apache Member
 Apache Karaf http://karaf.apache.org/ Committer  PMC
 OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer
 
 Project Lead
 blog http://notizblog.nierbeck.de/
 Co-Author of Apache Karaf Cookbook http://bit.ly/1ps9rkS

 Software Architect / Project Manager / Scrum Master




 --
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com


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



-- 
http://about.me/milen

Re: Datasource with Apache Felix.

2014-12-17 Thread Milen Dyankov

Don't get me wrong, I use Karaf myself and I love it. And I'm fully with
you about easy/flexible/enterprise ready container statement. Just was
trying to answer the question according to my best knowledge without
pushing on my personal preferences.

Best,
Milen

On Wed, Dec 17, 2014 at 3:27 PM, Jean-Baptiste Onofré j...@nanthrax.net
wrote:

 I agree, but Karaf is flexible enough to create your own custom
 distribution, where you easily assembly what you need.
 I know that some of you may think that OSGi is enough by itself, and a
 container doesn't make sense, but I disagree about that. Providing an
 easy/flexible/enterprise ready container on top of the framework is very
 interesting for the users.

 My $0.02

 Regards
 JB


 On 12/17/2014 03:22 PM, Milen Dyankov wrote:

 Well if someone says he wants to use B instead of A, I assume he/she has
 his reasons. That's why I tend to avoid answering like just stay with A
 as it doesn't really help. Besides, you don't really need everything Karaf
 comes with, in order to define and use datasources. Depends on the use
 case
 one may end up anywhere between installing 2-3 bundles to building custom
 Karaf.

 Best,
 Milen

 On Wed, Dec 17, 2014 at 2:46 PM, Jean-Baptiste Onofré j...@nanthrax.net
 wrote:


 Hi guys,

 if at the end, you install the same bundles as in Karaf (where we also
 bring some configuration and convenient commands), the question is why
 not
 directly using Karaf ;)

 Regards
 JB


 On 12/17/2014 02:44 PM, Milen Dyankov wrote:

  You probably know this but just to make it clear - Karaf is not directly
 comparable with Felix. It can use Felix or Equinox but it comes OOTB
 with
 many bundles pre-installed. That is why your datasource works in
 Karaf.
 It will work in Felix if you have appropriate bundles (that understand
 what
 datasource is, how is defined and how to deal with it) installed. In
 your
 case this is first the blueprint impl to process your blueprint config.
 Then it depend on what really a 'datasource' is in your case you'll need
 some more. Have a look at
 https://repo1.maven.org/maven2/org/apache/karaf/
 features/enterprise/3.0.2/enterprise-3.0.2-features.xml
 to see what Karaf uses if you want to stick with those implementations.
 There you'll see a jdbc, jpa, ... features and what bundles they
 consists of. Depending on what exactly is your use case, you may or may
 not
 need to install all of them!

 Best,
 Milen


 On Wed, Dec 17, 2014 at 2:05 PM, Achim Nierbeck 
 bcanh...@googlemail.com
 wrote:


 No I'm not saying that,
 but if he expects to use blueprint xml definitions for a datasource
 he'll
 need to put all those bundles back in again, in
 the end he might end up with the Karaf-minimal distro so where is the
 point?

 regards, Achim

 2014-12-17 14:02 GMT+01:00 Neil Bartlett njbartl...@gmail.com:


 Achim, are you seriously saying that you need the complete Karaf stack
 just in order to use a datasource?? That’s nuts.

 RamaKrishna, what is the issue you’re having? If you have a datasource
 bundle you can just install it in Felix and it will work. If not,
 please
 report the errors you get.

 Regards,
 Neil

   On 17 Dec 2014, at 12:51, Achim Nierbeck bcanh...@googlemail.com


  wrote:


 Any reason not to stick to Karaf as your container as it uses Felix
 as

  its

  framework?
 Otherwise you'll need to re-assemble the complete stack that is used

  inside

  Karaf.
 So you'll need to add the blueprint bundles first, those can be found

  at


  the Aries Project.

 Now you'll need to make sure you have Felix File install configured
 correctly and installed with your framework.
 For that you'll need some sort of main that does the bootstrapping of
 bundles that need to be part of the basic setup.
 ...
 I think I could go on for about 4 to 5 other projects you most likely

  would

  need.
 Again, why don't you stick to Karaf as it brings all of this
 infrastructural glueing?

 regards, Achim

 2014-12-17 12:13 GMT+01:00 Ramakrishna R ramakrishna...@gmail.com:


 Team,

 I want to know how to configure datasource in Felix container. I
 have

  a


  blueprint that contains datasource info, this i want to make work in


  Felix.


  In Karaf when i put it in deploy folder it works perfectly. Am not


  getting


  a direction as how to achive this in felix.


 --
 Cheers

 RamaKrishna RV



 --

 Apache Member
 Apache Karaf http://karaf.apache.org/ Committer  PMC
 OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/

  Committer


  

  Project Lead
 blog http://notizblog.nierbeck.de/
 Co-Author of Apache Karaf Cookbook http://bit.ly/1ps9rkS

 Software Architect / Project Manager / Scrum Master



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



  --

 Apache Member
 Apache Karaf http://karaf.apache.org/ Committer  PMC
 OPS4J Pax Web http://wiki.ops4j.org/display

Re: iPOJO and ManagedServiceFactory

2014-10-14 Thread Milen Dyankov

Thank you Clement,

It works now! I suppose there is no really a easy way to change the factory
PID in this case, right?

Regards,
Milen

On Mon, Oct 13, 2014 at 3:22 PM, Clement Escoffier
clement.escoff...@gmail.com wrote:

Hi,

On 13 octobre 2014 at 13:35:49, Milen Dyankov (milendyan...@gmail.com)
wrote:
Thank you for clarifying Clement!

The goal it pretty simple. Say I have:

@Component(
immediate = true,
managedservice = my.service)
@Provides
public class MyServiceImpl implements MyService {

@Property
protected String someProperty;
...
}

I would like to be able to able to create new instances (register new
services) by just creating respective my.service-unique_name.cfg files in
karaf's etc folder. This does not seem to work and up until now I thought
it's because the ManagedServiceFactory was not created. But if understand
correctly what you are saying - it should still work just use a different
approach internally. If that is correct, then must be something else I'm
doing wrong. I would appreciate any example (a pointer to a project using
something similar is more than enough) to learn from.

Remove the ‘managedservice’ attribute exposing a ManagedService and not
creating new instances. To create new instances, just create a cfg file
with the given name:

MyServiceImplQualifiedName-id.cfg

The “MyServiceImplQualifiedName” is the qualified name of your class (like
org.acme.component.MyServiceImpl)

Regards,

Clement

Regards,
Milen

On Mon, Oct 13, 2014 at 1:10 PM, Clement Escoffier
clement.escoff...@gmail.com wrote:

Hi,

You are right, 1.12.0 does not expose ManagedServiceFactory anymore
because it uses a ‘configuration tracker’
(org.apache.felix.ipojo.ConfigurationTracker). The documentation is not
up
to date. However, the feature stay the same. Factory configurations
pushed
in the config admin create instances et support dynamic reconfiguration.

Depending of what you want to do, you can also rely on the Factory
service
exposed for each @Component.

Cheers,

Clement

On 13 octobre 2014 at 12:02:36, Milen Dyankov (milendyan...@gmail.com)
wrote:

Hi,
can someone point me to an example of using ConfigAdmin's
ManagedServiceFactory with iPOJO components, please?

The reason I'm asking is, what the docs (

http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/combining-ipojo-and-configuration-admin.html

)
say:

For each (public) component type, a ManagedServiceFactory is published.
For each configurations matching with the component type from the
Configuration Admin, a new component instance is created.

does not seem to work for me (iPOJO 1.12.0 in Karaf 3.0.1). No matter
what
I do, I can't get a org.osgi.service.cm.ManagedServiceFactory
registered
for my component.

iPOJO will register org.osgi.service.cm.ManagedService for the
component
if I provide managedservice = . in the @Component and
@Instantiate
it! In such case I can indeed use ConfigAdmin to configure the instance.

However I couldn't figure out how to instruct iPOJO to register a
ManagedServiceFactory so that I can later on create new component
instances from ConfigAdmin. Am I misinterpreting the docs? Missing
something obvious?

Regards,
Milen

--
http://about.me/milen

iPOJO and ManagedServiceFactory

2014-10-13 Thread Milen Dyankov

Hi,
can someone point me to an example of using ConfigAdmin's
ManagedServiceFactory with iPOJO components, please?

The reason I'm asking is, what the docs  (
http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/combining-ipojo-and-configuration-admin.html)
say:

 For each (public) component type, a ManagedServiceFactory is published.
 For each configurations matching with the component type from the
 Configuration Admin, a new component instance is created.


does not seem to work for me (iPOJO 1.12.0 in Karaf 3.0.1). No matter what
I do, I can't get a org.osgi.service.cm.ManagedServiceFactory registered
for my component.

iPOJO will register org.osgi.service.cm.ManagedService for the component
if I provide managedservice = .  in the @Component and @Instantiate
it! In such case I can indeed use ConfigAdmin to configure the instance.

However I couldn't figure out how to instruct iPOJO to register a  
ManagedServiceFactory so that I can later on create new component
instances from ConfigAdmin. Am I misinterpreting the docs? Missing
something obvious?

Regards,
Milen


-- 
http://about.me/milen

Re: iPOJO and ManagedServiceFactory

2014-10-13 Thread Milen Dyankov

Thank you for clarifying Clement!

The goal it pretty simple. Say I have:

@Component(
immediate = true,
managedservice = my.service)
@Provides
public class MyServiceImpl implements MyService {

@Property
protected String someProperty;
...
}

Regards,
Milen

On Mon, Oct 13, 2014 at 1:10 PM, Clement Escoffier
clement.escoff...@gmail.com wrote:

Hi,

You are right, 1.12.0 does not expose ManagedServiceFactory anymore
because it uses a ‘configuration tracker’
(org.apache.felix.ipojo.ConfigurationTracker). The documentation is not up
to date. However, the feature stay the same. Factory configurations pushed
in the config admin create instances et support dynamic reconfiguration.

Depending of what you want to do, you can also rely on the Factory service
exposed for each @Component.

Cheers,

Clement

On 13 octobre 2014 at 12:02:36, Milen Dyankov (milendyan...@gmail.com)
wrote:

Hi,
can someone point me to an example of using ConfigAdmin's
ManagedServiceFactory with iPOJO components, please?

The reason I'm asking is, what the docs (

http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/combining-ipojo-and-configuration-admin.html
)
say:

For each (public) component type, a ManagedServiceFactory is published.
For each configurations matching with the component type from the
Configuration Admin, a new component instance is created.

does not seem to work for me (iPOJO 1.12.0 in Karaf 3.0.1). No matter what
I do, I can't get a org.osgi.service.cm.ManagedServiceFactory registered
for my component.

iPOJO will register org.osgi.service.cm.ManagedService for the component
if I provide managedservice = . in the @Component and @Instantiate
it! In such case I can indeed use ConfigAdmin to configure the instance.

Regards,
Milen

--
http://about.me/milen

IPojo injecting a service/component into manually created objects

2014-10-08 Thread Milen Dyankov

Hi everyone,

I faced a use case where I don't really know what is the best way to solve.
So here is oversimplified version of the problem:
 - I'm using a 3rd party framework (available as OSGI bundle) that does
something with objects (what exactly is irrelevant)
 - The framework is configured with some class names and it will create new
object instances as needed. However it allows you to hook into the object
creation phase and create the object yourself as long as you return new
object instance every time you are called.
 - I need to inject a OSGI services (iPOJO components) into the objects I
create for the 3rd party framework.

So I thought ideally those objects I create should be iPOJO components
themselves so that IPOJO can auto wire the services they require.  Thus I
was looking for a way to manually create a new instance of IPOJO components
on demand. What I managed to do is something like the code below in the
hook for the 3rd party framework (error handling removed for simplicity):

Factory factory =  // get the relevant factory using ServiceTracker
if (factory != null) {
ComponentInstance componentInstance;
try {
 componentInstance = factory.createComponentInstance(null);
 if (componentInstance instanceof InstanceManager) {
 InstanceManager instanceManager = (InstanceManager) componentInstance;
 Object pojoObject = instanceManager.getPojoObject();
if (pojoObject instanceof MyOwnType) {
 return (MyOwnType) pojoObject;
 }
 }
} catch (UnacceptableConfiguration | MissingHandlerException |
ConfigurationException e) {
}
}


This works but it feels somewhat too hacky. Is there a better way to do it?
Are there any drawbacks (performance, cleanup, ...)?

Regards,
Milen


-- 
http://about.me/milen

Re: iPojo @Stereotype annotated annotation from separate bundle

2014-09-29 Thread Milen Dyankov

I can but most likely not before next week.

Thanks

On Mon, Sep 29, 2014 at 1:00 AM, Guillaume Sauthier (OW2) 
guillaume@gmail.com wrote:

 Hi Milen

 Can you share a minimal project to help us reproduce the issue ?
 If you could zip it and attach it to a new JIRA, that would be great.

 Thanks

 --
 Guillaume Sauthier (OW2)
 Sent with Airmail

 On 22 Sep 2014 at 08:27:12, Clement Escoffier (clement.escoff...@gmail.com)
 wrote:

 Hi,

 Sorry for the late reply (should never change my email program).

 So, it should not be the case. As soon as the stereotype is available in
 the manipulator class path, it should be used. Obviously, if it’s in the
 bundle, it’s necessarily in the class path. Could you open an issue, it’s
 probably a bug.

 Cheers,

 Clement
 On 16 septembre 2014 at 10:57:46, Milen Dyankov (milendyan...@gmail.com)
 wrote:

 OK, my bad, I asked the question poorly.
 It of course works with private-package as well (I just used the export in
 my simple test).
 What I intended to ask was, why the stereotype class needs to be included
 in the bundle using it? In another words - isn't it enough that the bundle
 imports the package and the jar is on maven's classpath?

 On Mon, Sep 15, 2014 at 3:26 PM, Clement Escoffier 
 clement.escoff...@gmail.com wrote:

  Hi,
 
  Could you check that the stereotype class is actually included in the jar
  file when not exported ? Maybe the ‘private-package’ instruction contains
  the error.
 
  Cheers,
 
  Clement
 
  On 15 septembre 2014 at 15:05:17, Milen Dyankov (milendyan...@gmail.com)
  wrote:
 
  OK, found the problem. It's due to how Export-Package of
  the maven-bundle-plugin is configured.
 
  Here is an example:
  - I have stereotype maven project where I define a @Stereotype as
  *test.ipojo.stereotype*.MyComponent
  - The bundle maven project where I try to use the stereotype has its
  classes in the package *test.ipojo.bundle*
 
  When I have this in the bundle maven project :
 
 
 
 Export-Packagetest.ipojo.bundle*;version=${project.version}/Export-Package
 
  it does not work! What I see in the console is:
 
  [WARNING] Class test.ipojo.bundle.ComponentByStereotype has not been
 marked
  as a component type (no @Component, @Handler, ...). It will be ignored by
  the iPOJO manipulator.
 
  However changing this to:
 
  Export-Package*test.ipojo.stereotype**
  ,test.ipojo.bundle*;version=${project.version}/Export-Package
 
  works just fine.
 
  While I now know how to make it work, I'm still confused why do I need to
  export the stereotype package?
 
 
 
  On Mon, Sep 15, 2014 at 11:24 AM, Milen Dyankov milendyan...@gmail.com
  wrote:
 
   Thanks for explaining how it works Clement!
   I am indeed using maven and I tried to add the jar as a maven-ipojo-
   plugin dependency but it still does not seem to work.
   I'll play a bit with it and if it still does not work I'll try to
 extract
   and provide a simple example so you can eventually tell me what I'm
 doing
   wrong.
  
   Best,
   Milen
  
  
   On Sat, Sep 13, 2014 at 9:01 AM, Clement Escoffier 
   clement.escoff...@gmail.com wrote:
  
   Hi,
  
   Stereotypes are analyzed at build time, not at runtime. So they are
   packaged in regular jars. To work as expected, the stereotype need to
 be
   available from the ‘manipulator’ engine, in other words: be in the
 same
   class path.
  
   So, if you are using Maven, you can do as follows:
  
   plugin
   groupIdorg.apache.felix/groupId
   artifactIdmaven-ipojo-plugin/artifactId
   executions
   execution
   goals
   goalipojo-bundle/goal
   /goals
   /execution
   /executions
   dependencies
   dependency
   groupIdyour.groupId/groupId
   artifactIdyour.sterotype.artifactId/artifactId
   versionyour.version/version
   /dependency
   /dependencies
   /plugin
  
   Cheers,
  
   Clement
  
  
  
   On 13 septembre 2014 at 02:06:25, Milen Dyankov (
 milendyan...@gmail.com
  )
   wrote:
  
   Hi,
  
   Is the usage of a @Stereotype annotated annotation from another bundle
   supported? It doesn't seem to work even though the package is properly
   exported and imported.
  
   The docs only say:
  
   If the stereotyped annotation is directly in the manipulated module,
 no
problems: any front-end will work as expected.
If not, the different manipulator's front-end have variable support
  for
the stereotype feature.
  
  
   This is not very clear to me and to be honest I'm no sure what a
   manipulator's front-end is.
  
   Regards,
   Milen
  
  
  
   --
   http://about.me/milen
  
  
  
  
   --
   http://about.me/milen
  
 
 
 
  --
  http://about.me/milen
 



 --
 http://about.me/milen




-- 
http://about.me/milen

Re: iPojo @Stereotype annotated annotation from separate bundle

2014-09-16 Thread Milen Dyankov

OK, my bad, I asked the question poorly.
It of course works with private-package as well (I just used the export in
my simple test).
What I intended to ask was, why the stereotype class needs to be included
in the bundle using it? In another words - isn't it enough that the bundle
imports the package and the jar is on maven's classpath?

On Mon, Sep 15, 2014 at 3:26 PM, Clement Escoffier 
clement.escoff...@gmail.com wrote:

 Hi,

 Could you check that the stereotype class is actually included in the jar
 file when not exported ? Maybe the ‘private-package’ instruction contains
 the error.

 Cheers,

 Clement

 On 15 septembre 2014 at 15:05:17, Milen Dyankov (milendyan...@gmail.com)
 wrote:

 OK, found the problem. It's due to how Export-Package of
 the maven-bundle-plugin is configured.

 Here is an example:
 - I have stereotype maven project where I define a @Stereotype as
 *test.ipojo.stereotype*.MyComponent
 - The bundle maven project where I try to use the stereotype has its
 classes in the package *test.ipojo.bundle*

 When I have this in the bundle maven project :


 Export-Packagetest.ipojo.bundle*;version=${project.version}/Export-Package

 it does not work! What I see in the console is:

 [WARNING] Class test.ipojo.bundle.ComponentByStereotype has not been marked
 as a component type (no @Component, @Handler, ...). It will be ignored by
 the iPOJO manipulator.

 However changing this to:

 Export-Package*test.ipojo.stereotype**
 ,test.ipojo.bundle*;version=${project.version}/Export-Package

 works just fine.

 While I now know how to make it work, I'm still confused why do I need to
 export the stereotype package?



 On Mon, Sep 15, 2014 at 11:24 AM, Milen Dyankov milendyan...@gmail.com
 wrote:

  Thanks for explaining how it works Clement!
  I am indeed using maven and I tried to add the jar as a maven-ipojo-
  plugin dependency but it still does not seem to work.
  I'll play a bit with it and if it still does not work I'll try to extract
  and provide a simple example so you can eventually tell me what I'm doing
  wrong.
 
  Best,
  Milen
 
 
  On Sat, Sep 13, 2014 at 9:01 AM, Clement Escoffier 
  clement.escoff...@gmail.com wrote:
 
  Hi,
 
  Stereotypes are analyzed at build time, not at runtime. So they are
  packaged in regular jars. To work as expected, the stereotype need to be
  available from the ‘manipulator’ engine, in other words: be in the same
  class path.
 
  So, if you are using Maven, you can do as follows:
 
  plugin
  groupIdorg.apache.felix/groupId
  artifactIdmaven-ipojo-plugin/artifactId
  executions
  execution
  goals
  goalipojo-bundle/goal
  /goals
  /execution
  /executions
  dependencies
  dependency
  groupIdyour.groupId/groupId
  artifactIdyour.sterotype.artifactId/artifactId
  versionyour.version/version
  /dependency
  /dependencies
  /plugin
 
  Cheers,
 
  Clement
 
 
 
  On 13 septembre 2014 at 02:06:25, Milen Dyankov (milendyan...@gmail.com
 )
  wrote:
 
  Hi,
 
  Is the usage of a @Stereotype annotated annotation from another bundle
  supported? It doesn't seem to work even though the package is properly
  exported and imported.
 
  The docs only say:
 
  If the stereotyped annotation is directly in the manipulated module, no
   problems: any front-end will work as expected.
   If not, the different manipulator's front-end have variable support
 for
   the stereotype feature.
 
 
  This is not very clear to me and to be honest I'm no sure what a
  manipulator's front-end is.
 
  Regards,
  Milen
 
 
 
  --
  http://about.me/milen
 
 
 
 
  --
  http://about.me/milen
 



 --
 http://about.me/milen




-- 
http://about.me/milen

Re: iPojo @Stereotype annotated annotation from separate bundle

2014-09-15 Thread Milen Dyankov

OK,  found the problem. It's due to how Export-Package of
the maven-bundle-plugin is configured.

Here is an example:
- I have stereotype maven project where I define a @Stereotype as
*test.ipojo.stereotype*.MyComponent
- The bundle maven project where I try to use the stereotype has its
classes in the package *test.ipojo.bundle*

When I have this in the bundle maven project :

Export-Packagetest.ipojo.bundle*;version=${project.version}/Export-Package

it does not work! What I see in the console is:

[WARNING] Class test.ipojo.bundle.ComponentByStereotype has not been marked
as a component type (no @Component, @Handler, ...). It will be ignored by
the iPOJO manipulator.

However changing this to:

Export-Package*test.ipojo.stereotype**
,test.ipojo.bundle*;version=${project.version}/Export-Package

works just fine.

While I now know how to make it work, I'm still confused why do I need to
export the stereotype package?



On Mon, Sep 15, 2014 at 11:24 AM, Milen Dyankov milendyan...@gmail.com
wrote:

 Thanks for explaining how it works Clement!
 I am indeed using maven and I tried to add the jar as a maven-ipojo-
 plugin dependency but it still does not seem to work.
 I'll play a bit with it and if it still does not work I'll try to extract
 and provide a simple example so you can eventually tell me what I'm doing
 wrong.

 Best,
 Milen


 On Sat, Sep 13, 2014 at 9:01 AM, Clement Escoffier 
 clement.escoff...@gmail.com wrote:

 Hi,

 Stereotypes are analyzed at build time, not at runtime. So they are
 packaged in regular jars. To work as expected, the stereotype need to be
 available from the ‘manipulator’ engine, in other words: be in the same
 class path.

 So, if you are using Maven, you can do as follows:

 plugin
 groupIdorg.apache.felix/groupId
 artifactIdmaven-ipojo-plugin/artifactId
 executions
 execution
 goals
 goalipojo-bundle/goal
 /goals
 /execution
 /executions
 dependencies
 dependency
 groupIdyour.groupId/groupId
 artifactIdyour.sterotype.artifactId/artifactId
 versionyour.version/version
 /dependency
 /dependencies
 /plugin

 Cheers,

 Clement



 On 13 septembre 2014 at 02:06:25, Milen Dyankov (milendyan...@gmail.com)
 wrote:

 Hi,

 Is the usage of a @Stereotype annotated annotation from another bundle
 supported? It doesn't seem to work even though the package is properly
 exported and imported.

 The docs only say:

 If the stereotyped annotation is directly in the manipulated module, no
  problems: any front-end will work as expected.
  If not, the different manipulator's front-end have variable support for
  the stereotype feature.


 This is not very clear to me and to be honest I'm no sure what a
 manipulator's front-end is.

 Regards,
 Milen



 --
 http://about.me/milen




 --
 http://about.me/milen




-- 
http://about.me/milen

iPojo @Stereotype annotated annotation from separate bundle

2014-09-12 Thread Milen Dyankov

Hi,

Is the usage of a @Stereotype annotated annotation from another bundle
supported? It doesn't seem to work even though the package is properly
exported and imported.

The docs only say:

If the stereotyped annotation is directly in the manipulated module, no
 problems: any front-end will work as expected.
 If not, the different manipulator's front-end have variable support for
 the stereotype feature.


This is not very clear to me and to be honest I'm no sure what a
manipulator's front-end is.

Regards,
Milen



-- 
http://about.me/milen

Re: IPojo method annotated with @Updated called twice

2014-09-01 Thread Milen Dyankov

Thanks,

I'll be watching the issue. Meanwhile do you have any idea how to work
around it?

Regards,
Milen



On Mon, Sep 1, 2014 at 7:21 AM, Clement Escoffier 
clement.escoff...@gmail.com wrote:

 Hi,

 It seems that the bug is back. I’ve re-opened the issue.

 Thanks,

 Clement

 On 31 août 2014 at 12:24:49, Milen Dyankov (milendyan...@gmail.com) wrote:

 Hi everyone,

 I'm aware this issue has been reported (FELIX-4172) and apparently fixed in
 ipojo-runtime-1.11.0. However the same (or very similar one) happens in
 Karaf 3.0.1 with IPojo 1.12.0.

 Here is my very simple test class:

 @Component(
 immediate = true,
 managedservice = update.test)
 @Provides
 @Instantiate
 public class UpdateTest implements TestInterface {

 @Override
 public void test() {
 }

 @Updated
 public void update(Dictionary dictionary) {
 Thread t = Thread.currentThread();
 System.out.println();
 System.out.println(PROPERTIES UPDATED \n +
  in thread: [ + t.getName() + ] \n +
  values:  + dictionary);
 }

 }

 In Karaf I have a simple update.test.cfg file containing 
 test.property=test.value!

 When I deploy my bundle in Karaf this is what I get:

 PROPERTIES UPDATED
 in thread: [[iPOJO] pool-1-thread-1]
 values: {test.property=test.value, component=test.UpdateTest,

 felix.fileinstall.filename=file:/data/projects/tmp/karaf/apache-karaf-3.0.1/etc/update.test.cfg}
 PROPERTIES UPDATED
 in thread: [CM Configuration Updater (ManagedService Update:
 pid=[update.test])]
 values: {test.property=test.value, component=test.UpdateTest,

 felix.fileinstall.filename=file:/data/projects/tmp/karaf/apache-karaf-3.0.1/etc/update.test.cfg}


 Is this a bug?

 --
 http://about.me/milen




-- 
http://about.me/milen

IPojo method annotated with @Updated called twice

2014-08-31 Thread Milen Dyankov

Hi everyone,

I'm aware this issue has been reported (FELIX-4172) and apparently fixed in
ipojo-runtime-1.11.0. However the same (or very similar one) happens in
Karaf 3.0.1 with IPojo 1.12.0.

Here is my very simple test class:

@Component(
immediate = true,
managedservice = update.test)
@Provides
@Instantiate
public class UpdateTest implements TestInterface {

@Override
public void test() {
}

@Updated
public void update(Dictionary dictionary) {
Thread t = Thread.currentThread();
System.out.println();
System.out.println(PROPERTIES UPDATED \n +
 in thread: [ + t.getName() + ] \n +
 values:  + dictionary);
}

}

In Karaf I have a simple update.test.cfg file containing 
test.property=test.value!

When I deploy my bundle in Karaf this is what I get:

PROPERTIES UPDATED
 in thread: [[iPOJO] pool-1-thread-1]
 values: {test.property=test.value, component=test.UpdateTest,
felix.fileinstall.filename=file:/data/projects/tmp/karaf/apache-karaf-3.0.1/etc/update.test.cfg}
PROPERTIES UPDATED
 in thread: [CM Configuration Updater (ManagedService Update:
pid=[update.test])]
 values: {test.property=test.value, component=test.UpdateTest,
felix.fileinstall.filename=file:/data/projects/tmp/karaf/apache-karaf-3.0.1/etc/update.test.cfg}


Is this a bug?

-- 
http://about.me/milen

Re: Re: Felix and Pax Logging

Re: Felix and Pax Logging

Re: Fw: Mem Leak

Re: API baselining with maven-bundle-plugin

Re: setting the objectclassdefinition from felix file install

[Ann] Modularity Conference in Darmstadt Germany : ModConf

Re: Specifying dependency between a bundle and a fragment bundle

Specifying dependency between a bundle and a fragment bundle

Re: Specifying dependency between a bundle and a fragment bundle

Re: Specifying dependency between a bundle and a fragment bundle

Re: Bundle can't find its own classes: NoClassDefFoundError

Re: Bundle can't find its own classes: NoClassDefFoundError

Re: Core and Compendium APIS at runtime

Re: Core and Compendium APIS at runtime

Re: Core and Compendium APIS at runtime

Core and Compendium APIS at runtime

Re: OSGi Declarative Services dependency on a generic supertype

Re: OSGi Declarative Services dependency on a generic supertype

Re: OSGi Declarative Services dependency on a generic supertype

Re: OSGi Declarative Services dependency on a generic supertype

Re: OSGi Declarative Services dependency on a generic supertype

Re: Getting a reference to a declarative service

Re: Datasource with Apache Felix.

Re: Datasource with Apache Felix.

Re: Datasource with Apache Felix.

Re: iPOJO and ManagedServiceFactory

iPOJO and ManagedServiceFactory

Re: iPOJO and ManagedServiceFactory

IPojo injecting a service/component into manually created objects

Re: iPojo @Stereotype annotated annotation from separate bundle

Re: iPojo @Stereotype annotated annotation from separate bundle

Re: iPojo @Stereotype annotated annotation from separate bundle

iPojo @Stereotype annotated annotation from separate bundle

Re: IPojo method annotated with @Updated called twice

IPojo method annotated with @Updated called twice

35 matches

Site Navigation

Mail list logo

Footer information