[FileInstall] please release
Hi Could you please do a release for FileInstall? I've asked a few times already on the bug report (https://issues.apache.org/jira/browse/FELIX-5261) but the JIRA doesn't seem to be used that well. -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: scr claims to be unsatisfied for service that seems to be there
On 12/08/16 12:02, Carsten Ziegeler wrote: Thanks Carsten, that was my expectation but I was waiting for the “inspect cap service” output to confirm. One thing that can be quite confusing is that the service references, with cardinality of 1..1, are described as both satisfied and unbound. This sounds like a contradiction until you realise the component has not yet been instantiated. I assume that SCR at this point does know which services it *will* bind when the component is activated… maybe these could be shown here? I think that would be misleading because when the bundle composition changes before activation is needed then a different resolution can/will be activated. Hmm, yeah we could do that - on the other hand "unbound" means it's satisfied, otherwise it would state the reference as "unsatisfied" :) Maybe, it's more a wording problem? Carsten -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: DS: invalid/alarmist circular reference log
The mandatory reference:
VpnRemotes vpnRemotes = null;
@Reference(policyOption = ReferencePolicyOption.GREEDY)
public void setVpnRemotes(final VpnRemotes vpnRemotes) {
this.vpnRemotes = vpnRemotes;
}
The optional reference:
private final Set clients = new CopyOnWriteArraySet<>();
@Reference(policyOption = ReferencePolicyOption.GREEDY, policy =
ReferencePolicy.DYNAMIC,
cardinality = ReferenceCardinality.MULTIPLE)
public void addVPNRemotesClient(final VpnRemotesClient client) {
this.clients.add(client);
}
public void removeVPNRemotesClient(final VpnRemotesClient client) {
this.clients.remove(client);
}
F.
On 12/05/16 18:09, David Jencks wrote:
Can you verify that your case is the same as Victor’s? All the circular
references I encounter work fine, if there are 2 different broken cases that
would be good to know when investigating Victor’s case.
thanks
david jencks
On May 12, 2016, at 2:58 AM, Ferry Huberts <maili...@hupie.com> wrote:
On 12/05/16 11:55, Victor Antonovich wrote:
12.05.2016 12:42, Ferry Huberts wrote:
Hi,
I'm seeing log lines like:
[some.component(17)] Circular reference detected, getService returning
null
These are invalid for my application since one end of the relation is
mandatory and the other end is optional.
DS should not complain in this way when at least one end of the relation
is optional.
(I can't file an issue on this since JIRA seems to be in some kind of
lockdown)
Fyi, this issue already has been filed a while ago:
https://issues.apache.org/jira/browse/FELIX-4417
ok, tnx
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
<mailto:users-unsubscr...@felix.apache.org>
For additional commands, e-mail: users-h...@felix.apache.org
<mailto:users-h...@felix.apache.org>
--
Ferry Huberts
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: DS: invalid/alarmist circular reference log
On 12/05/16 11:55, Victor Antonovich wrote: 12.05.2016 12:42, Ferry Huberts wrote: Hi, I'm seeing log lines like: [some.component(17)] Circular reference detected, getService returning null These are invalid for my application since one end of the relation is mandatory and the other end is optional. DS should not complain in this way when at least one end of the relation is optional. (I can't file an issue on this since JIRA seems to be in some kind of lockdown) Fyi, this issue already has been filed a while ago: https://issues.apache.org/jira/browse/FELIX-4417 ok, tnx - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
DS: invalid/alarmist circular reference log
Hi, I'm seeing log lines like: [some.component(17)] Circular reference detected, getService returning null These are invalid for my application since one end of the relation is mandatory and the other end is optional. DS should not complain in this way when at least one end of the relation is optional. (I can't file an issue on this since JIRA seems to be in some kind of lockdown) -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Plaintext password in configuration files for Jetty and Webconsole
So thanks for all the replies. But especially for webconsole, the password can be a hash, much like is the /etc/passwd files on Unix systems. Would a feature request bug on this make any chance when I file it? On 24/04/16 13:18, Roland Tepp wrote: Console (weather accessed over web or ssh) should be a trusted environment. If a untrusted user gains access to you console you have much more serious problems than access to some configuration options. On Sun, 24 Apr 2016 at 02:29, Carsten Ziegeler <cziege...@apache.org> wrote: Peter Kriens wrote You could adjust cm to recognize a macro and expand that macro to something local like a file, a system property, or an environment variable. That is how I solved it in the Configurer. Works very well on Travis that allows you to configure with encrypted data that is decrypted as environment variables. This still has the problem that the decrypted data is visible to everyone (via web console etc.) Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Plaintext password in configuration files for Jetty and Webconsole
Thanks Neil This is what I thought/feared. To me, at least the webconsole doesn't need a plaintext password and can use the same hashing mechanism the Unices use. Carsten? The keystore password would be more difficult. On 22/04/16 23:34, Neil Bartlett wrote: This is a tricky one… the components need to receive the password in plaintext, and FileInstall does not support decryption. You could build a management agent that supports reading encrypted data, either at the individual field level or over the whole configuration file. You still have the problem of how to supply the decryption key, and this very much depends on your specific requirements. For example the app could prompt for a password at startup time. Neil On 22 Apr 2016, at 09:00, Antonio Sanso <asa...@adobe.com> wrote: hi, I would actually have the same question? Is there anything can be done here ? If not there is any plan to improve this? I might try to help out in this area providing a patch… Anyone :)? regards antonio On Apr 20, 2016, at 5:07 PM, Ferry Huberts <maili...@hupie.com> wrote: Hi I use FileInstall to push config into ConfigAdmin. Now for Jettry and WebConsole there are plaintext passwords in there and I could not find how to avoid that. Is there a way to avoid plaintext password? Below is an example. org.apache.felix.http.cfg: org.apache.felix.https.keystore.password=mypassword org.apache.felix.webconsole.internal.servlet.OsgiManager.cfg: password=mypassword -- Ferry Huberts - 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 - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Plaintext password in configuration files for Jetty and Webconsole
Hi I use FileInstall to push config into ConfigAdmin. Now for Jettry and WebConsole there are plaintext passwords in there and I could not find how to avoid that. Is there a way to avoid plaintext password? Below is an example. org.apache.felix.http.cfg: org.apache.felix.https.keystore.password=mypassword org.apache.felix.webconsole.internal.servlet.OsgiManager.cfg: password=mypassword -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: configuration with new (R6) @interface and OSGi annotations
See http://pelagic-open-source.blogspot.nl/2015/08/convert-to-osgi-r6.html
You probably need these bnd instructions:
-metatypeannotations: *
-dsannotations: *
And maybe even:
-dsannotations-options: inherit
On 25/11/15 17:55, Oliver Lietz wrote:
On Wednesday 25 November 2015 14:27:28 Carsten Ziegeler wrote:
Hi,
Hi Carsten,
not sure what @interface is,
the custom configuration annotation itself, as in your sample:
public @interface Config {
@AttributeDefinition(name="Easy", description="Maximum value for
easy")
but I have a working example at:
https://github.com/cziegeler/samples.guessinggame
It does not compile because of the HTTP Whiteboard dependency, but helps
though.
The element Designate in metatype's MetaData is missing from the generated
XML. Will investigate what goes wrong.
Regards,
O.
Carsten
Oliver Lietz wrote
hi,
can someone point me to an example of @interface configuration with Maven
Bundle Plugin and OSGi annotations where the configuration is editable by
Web Console (metatype)?
My component is annotated with @Designate(ocd = Configuration.class) and
the configuration gets injected in the activate method, but the
configuration doesn't show up in Web Console (Karaf 4.0.3).
Is there anything special to look at in the generated XML?
Thanks,
O.
-
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
--
Ferry Huberts
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: DRY for DS?
On 17/11/15 19:00, Benson Margulies wrote: I'm feeling a bit sad; I have a family of 12 very similar services, but I can't put the @Reference, @Activate, and @Deactivate into the base class, I have to copy and paste it into each component class. Have I missed an alternative? (bnd instructions) -dsannotations: * -dsannotations-options: inherit -metatypeannotations: * The relevant one is the 'inherit' one. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: DRY for DS?
For bnd you really do need the @Activate and @Deactivate annotations, otherwise the component XML doesn't specify them On 17/11/15 20:57, Robert Munteanu wrote: On Tue, Nov 17, 2015 at 9:47 PM, Benson Margulies <ben...@basistech.com> wrote: On Tue, Nov 17, 2015 at 2:43 PM, Robert Munteanu <romb...@apache.org> wrote: Hi Benson, On Tue, Nov 17, 2015 at 8:00 PM, Benson Margulies <ben...@basistech.com> wrote: I'm feeling a bit sad; I have a family of 12 very similar services, but I can't put the @Reference, @Activate, and @Deactivate into the base class, I have to copy and paste it into each component class. Have I missed an alternative? The @Activate and @Deactivate annotations are optional if you stick to the standard 'activate' and 'deactivate' method names. I've also got some @References being repeated. As far as 'standard' goes, this is the standard that specs how bnd turns .class files into XML? So my only concern would be that some other tool might not do it? The default activate and deactivate method names are not tied to bnd. They are considered when these method names are not defined in the XML descriptor. Robert -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Uninstalled API bundle, yet implementation still resolves and starts
-- 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 <mailto:users-unsubscr...@felix.apache.org> <mailto:users-unsubscr...@felix.apache.org <mailto:users-unsubscr...@felix.apache.org>> For additional commands, e-mail: users-h...@felix.apache.org <mailto:users-h...@felix.apache.org> <mailto:users-h...@felix.apache.org <mailto:users-h...@felix.apache.org>> - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org <mailto:users-unsubscr...@felix.apache.org> For additional commands, e-mail: users-h...@felix.apache.org <mailto:users-h...@felix.apache.org> -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
@Reference multi binding & dynamics
Hi, Cross-posting because I don't know if the situation/problem below is by design, a bug in bnd, or a bug in SCR I have a R6 component that does @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE) This appears to not bind new matching services, because the policy appears to be STATIC by default. I did expect the ReferenceCardinality.AT_LEAST_ONE to imply ReferencePolicy.DYNAMIC, just like the bnd annotations did. Changing it to @Reference(policy = ReferencePolicy.DYNAMIC, cardinality = ReferenceCardinality.AT_LEAST_ONE) appears to make it work like I expected. Is this by design? Coming from bnd annotations this - to me - seems like another (breaking) subtlety. -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: @Reference multi binding & dynamics
On 07/10/15 18:01, Neil Bartlett wrote: On 7 Oct 2015, at 13:56, Ferry Huberts <maili...@hupie.com> wrote: Hi, Cross-posting because I don't know if the situation/problem below is by design, a bug in bnd, or a bug in SCR I have a R6 component that does @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE) This appears to not bind new matching services, because the policy appears to be STATIC by default. Yes, static policy has always been the default in DS. You can see this right back in the very first DS specification found in OSGi Compendium R4.0, section 112.3.3: "The static policy is the most simple policy and is the default policy”. Also section 112.10 that gives the XML schema, where the reference element has the policy attribute defined as: I did expect the ReferenceCardinality.AT_LEAST_ONE to imply ReferencePolicy.DYNAMIC, just like the bnd annotations did. Nope. These are new annotations in a new namespace. There is no reason to expect them to have the same behaviour as the bnd annotations. However, I challenge you to give me _one_ use-case where ReferencePolicy.STATIC && ReferencePolicy.(MULTIPLE|AT_LEAST_ONE) makes sense... That combination _creates_ a timing dependency, services might or might not be bound, depending on startup order. A warning in bndtools like 'you probably meant to use ReferencePolicy.DYNAMIC' when havingReferencePolicy.MULTIPLE or ReferencePolicy.AT_LEAST_ONE would be nice IMHO Changing it to @Reference(policy = ReferencePolicy.DYNAMIC, cardinality = ReferenceCardinality.AT_LEAST_ONE) appears to make it work like I expected. Is this by design? Coming from bnd annotations this - to me - seems like another (breaking) subtlety. It’s a subtlety perhaps because the standard annotations are just a direct, literal transformation to the XML, whereas the bnd ones tried to be “smart”. Yes, this is by design. It’s certainly not breaking because, again, these are new annotations and there is no reason to expect them to do the same thing… -- Ferry Huberts -- You received this message because you are subscribed to the Google Groups "bndtools-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: @Reference multi binding & dynamics
copy/paste error... On 07/10/15 18:01, Neil Bartlett wrote: On 7 Oct 2015, at 13:56, Ferry Huberts <maili...@hupie.com> wrote: Hi, Cross-posting because I don't know if the situation/problem below is by design, a bug in bnd, or a bug in SCR I have a R6 component that does @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE) This appears to not bind new matching services, because the policy appears to be STATIC by default. Yes, static policy has always been the default in DS. You can see this right back in the very first DS specification found in OSGi Compendium R4.0, section 112.3.3: "The static policy is the most simple policy and is the default policy”. Also section 112.10 that gives the XML schema, where the reference element has the policy attribute defined as: I did expect the ReferenceCardinality.AT_LEAST_ONE to imply ReferencePolicy.DYNAMIC, just like the bnd annotations did. Nope. These are new annotations in a new namespace. There is no reason to expect them to have the same behaviour as the bnd annotations. However, I challenge you to give me _one_ use-case where ReferencePolicy.STATIC && ReferenceCardinality.(MULTIPLE|AT_LEAST_ONE) makes sense... That combination _creates_ a timing dependency, services might or might not be bound, depending on startup order. A warning in bndtools like 'you probably meant to use ReferencePolicy.DYNAMIC' when having ReferenceCardinality.MULTIPLE or ReferenceCardinality.AT_LEAST_ONE would be nice IMHO Changing it to @Reference(policy = ReferencePolicy.DYNAMIC, cardinality = ReferenceCardinality.AT_LEAST_ONE) appears to make it work like I expected. Is this by design? Coming from bnd annotations this - to me - seems like another (breaking) subtlety. It’s a subtlety perhaps because the standard annotations are just a direct, literal transformation to the XML, whereas the bnd ones tried to be “smart”. Yes, this is by design. It’s certainly not breaking because, again, these are new annotations and there is no reason to expect them to do the same thing… -- Ferry Huberts -- You received this message because you are subscribed to the Google Groups "bndtools-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: @Reference multi binding & dynamics
On 07/10/15 18:22, David Jencks wrote: Another use case is where you have set the .cardinality.minimum property to the expected number of actual services. I can see Tim's case, but this one is rather icky/hackish to me. It implies knowledge of how the component is going to be deployed. Anyway, it's all cleared up now as being by design and I fixed up my code, so thanks to all. david jencks On Oct 7, 2015, at 12:17 PM, Tim Ward <tim.w...@paremus.com <mailto:tim.w...@paremus.com>> wrote: Sent from my iPhone On 7 Oct 2015, at 18:13, Ferry Huberts <maili...@hupie.com <mailto:maili...@hupie.com>> wrote: On 07/10/15 18:01, Neil Bartlett wrote: On 7 Oct 2015, at 13:56, Ferry Huberts <maili...@hupie.com <mailto:maili...@hupie.com>> wrote: Hi, Cross-posting because I don't know if the situation/problem below is by design, a bug in bnd, or a bug in SCR I have a R6 component that does @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE) This appears to not bind new matching services, because the policy appears to be STATIC by default. Yes, static policy has always been the default in DS. You can see this right back in the very first DS specification found in OSGi Compendium R4.0, section 112.3.3: "The static policy is the most simple policy and is the default policy”. Also section 112.10 that gives the XML schema, where the reference element has the policy attribute defined as: use="optional"/> I did expect the ReferenceCardinality.AT_LEAST_ONE to imply ReferencePolicy.DYNAMIC, just like the bnd annotations did. Nope. These are new annotations in a new namespace. There is no reason to expect them to have the same behaviour as the bnd annotations. However, I challenge you to give me _one_ use-case where ReferencePolicy.STATIC && ReferencePolicy.(MULTIPLE|AT_LEAST_ONE) makes sense... That combination _creates_ a timing dependency, services might or might not be bound, depending on startup order. You don't need to be dynamic if your reference is greedy. That will eagerly pick up new services as they arrive too, just restarting the component when it changes. A warning in bndtools like 'you probably meant to use ReferencePolicy.DYNAMIC' when havingReferencePolicy.MULTIPLE or ReferencePolicy.AT_LEAST_ONE would be nice IMHO Changing it to @Reference(policy = ReferencePolicy.DYNAMIC, cardinality = ReferenceCardinality.AT_LEAST_ONE) appears to make it work like I expected. Is this by design? Coming from bnd annotations this - to me - seems like another (breaking) subtlety. It’s a subtlety perhaps because the standard annotations are just a direct, literal transformation to the XML, whereas the bnd ones tried to be “smart”. Yes, this is by design. It’s certainly not breaking because, again, these are new annotations and there is no reason to expect them to do the same thing… -- Ferry Huberts -- You received this message because you are subscribed to the Google Groups "bndtools-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscr...@googlegroups.com <mailto:bndtools-users+unsubscr...@googlegroups.com>. For more options, visit https://groups.google.com/d/optout. -- Ferry Huberts -- You received this message because you are subscribed to the Google Groups "bndtools-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscr...@googlegroups.com <mailto:bndtools-users+unsubscr...@googlegroups.com>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "bndtools-users" group. To unsubscribe from this group and stop receiving emails from it, send an email tobndtools-users+unsubscr...@googlegroups.com <mailto:bndtools-users+unsubscr...@googlegroups.com>. For more options, visithttps://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "bndtools-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscr...@googlegroups.com <mailto:bndtools-users+unsubscr...@googlegroups.com>. For more options, visit https://groups.google.com/d/optout. -- Ferry Huberts
Re: cannot delete bundle jar from load directory (locked)
This is an inherent problem of using native code. AFAIK, once a library is loaded, it can't be unloaded, neither on Windows nor on Linux or Mac; the library remains in the address space of the process that loaded it, which in this case is the Java runtime. The only way to unload the library is to stop the process, which obviously kills your use-case. This is exactly the same problem as the Celix guys have (they're building an OSGi framework implementation in C). On Windows there are file locks on the bundle with the native libraries, on Linux there are no such locks (IIRC). Still, removing the bundle while its native libraries were loaded is kind-of cheating and tricky at best. Until the C libraries of our OSes provide us with a way to unload a library we're stuck with this problem. On 21/08/15 21:10, Hubert Felber wrote: Did you refresh after uninstalling ? yes, stop - uninstall - refresh it did not help Thank you Hubert Richard S. Hall he...@ungoverned.org 21.08.2015 20:28 On 8/21/15 14:24 , Hubert Felber wrote: Windows :-) 1. stop the bundle before deleting its bundle neither stop nor uninstall the bundle helps. It must have to do with the native code running -- is still locked. Did you refresh after uninstalling ? 2. stop using windows, by far the best choice IMHO :-) well, since our customers insist of using windows regards Hubert Ferry Huberts maili...@hupie.com 21.08.2015 20:08 On 21/08/15 20:05, Hubert Felber wrote: Hi, I cannot delete a certain bundle jar from load directory, while I can do this with others in the same load directory while they are running. It says that this is open by java -- I do not receive a stop event in the activator. This specific bundle has embedded jniWrapper jar and lots of native libraries (dlls). The jniWrapper is active and the native libraries are loaded. What could cause this lock? Windows Can I do anything to avoid this lock? 1. stop the bundle before deleting its bundle 2. stop using windows, by far the best choice IMHO :-) - 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 - 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 -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: cannot delete bundle jar from load directory (locked)
On 21/08/15 20:05, Hubert Felber wrote: Hi, I cannot delete a certain bundle jar from load directory, while I can do this with others in the same load directory while they are running. It says that this is open by java -- I do not receive a stop event in the activator. This specific bundle has embedded jniWrapper jar and lots of native libraries (dlls). The jniWrapper is active and the native libraries are loaded. What could cause this lock? Windows Can I do anything to avoid this lock? 1. stop the bundle before deleting its bundle 2. stop using windows, by far the best choice IMHO :-) - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Gradle OBR?
There is OBR (and R5) indexing support in my bndtools Gradle plugin (https://marketplace.eclipse.org/content/bndtools-plugins-pelagic). Check the code here: https://github.com/fhuberts/bndtoolsPlugins. Read https://github.com/fhuberts/bndtoolsPlugins/blob/master/nl.pelagic.bndtools.headless.build.plugin.gradle/resources/templates/unprocessed/cnf/gradle/doc/BUILDING-GRADLE.md#BuildTasksIndex and then look at the code https://github.com/fhuberts/bndtoolsPlugins/blob/master/nl.pelagic.bndtools.headless.build.plugin.gradle/resources/templates/unprocessed/cnf/gradle/template/index.gradle. You can use the code as long as you comply with the GPLv2 license, which just means that you contribute changes back :-) On 25/02/15 08:24, Johan Ström wrote: Hi, while not strictly a Felix question, I'd like to crosspost a question I have regarding Gradle, OSGi and OBR here, as I hope there might be someone out there who has a good answer.. :) (Originally posted on: http://stackoverflow.com/questions/28698190/gradle-osgi-and-obr-or-other-repository) Previously I've been using Maven and the maven-bundle-plugin to archive the following: When doing mvn install, local maven repo contains my bundle + all my bundle's deps automatically * Local repo becomes OBR repository by mvn bundle:index, also repository.xml is automatically updated with every mvn install. * Local repo can now be used for Karaf bundle deployment Now, I'm looking to migrate some projects to Gradle, which is very nice in many ways. I'm successfully creating bundles using the 'org.dm.bundle' plugin (basic 'osgi' plugin did not allow me to auto-create service components). By using Gradle's maven plugin I can do gradle install to install my own bundle in local maven repo. I could then use bindex to manually (or through some gradle hacking) index the repo. However, my dependencies are not put into the maven repo, they are only stored in the gradle cache dir. Thus, I can not use the OBR repo to deploy in Karaf yet. I've been looking around a lot trying to find some good solution to this, but I have not found anything. I've looked at Karaf feature files, which would allow me to specify mvn URLs directly instead of relying on OBR, but I'd like to avoid messing with feature files manually, or all together if possible. There are references to using Nexus, but only Nexus Pro supports OBR from what I can see? I'm up for suggestions on alternative solutions as well; the main goal is that I shall be able to deploy my bundles + deps in Karaf. Maven does not have to be used at all really, although I need some way for different Gradle projects to find dependencies from some other projects (which are not part of the same multi-project). Any ideas or discussions to put me on the right track is appreciated! Thanks! -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: OSGi Declarative Services dependency on a generic supertype
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
Re: OSGi Declarative Services dependency on a generic supertype
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
Re: OSGi Declarative Services dependency on a generic supertype
On 05/02/15 17: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? Don't know about SCR annotations, never used them. In general your bundles should really advertise only/all of the interfaces you want/need. Your bundles can also advertise _only_ the supertype. It really depends on your needs. So, no clear answer :-) - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: maven bundle plugin and baselining
On 11/11/14 20:10, mit_jones wrote: I have read the same http://www.aqute.biz/Bnd/Versioning Baselining compares the public API of a bundle with the public API of another bundle however this isn't the behaviour I have seen when using the bnd Eclipse plugin where a recommendation to bump the micro version is made. This is explained a bit more in http://www.planetmarrs.net/semantic-versioning-in-osgi/ and http://www.planetmarrs.net/semantic-versioning-and-continuous-integration/ where it explains that the baselining feature of Bndtools uses bytecode analysis so will detect any change to the code not just a public API change. It detects changes in all classes. The version bump is based only on changes in exported classes - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: maven bundle plugin and baselining
On 11/11/14 20:59, Ferry Huberts wrote: On 11/11/14 20:10, mit_jones wrote: I have read the same http://www.aqute.biz/Bnd/Versioning Baselining compares the public API of a bundle with the public API of another bundle however this isn't the behaviour I have seen when using the bnd Eclipse plugin where a recommendation to bump the micro version is made. This is explained a bit more in http://www.planetmarrs.net/semantic-versioning-in-osgi/ and http://www.planetmarrs.net/semantic-versioning-and-continuous-integration/ where it explains that the baselining feature of Bndtools uses bytecode analysis so will detect any change to the code not just a public API change. It detects changes in all classes. The version bump is based only on changes in exported classes That is, the major and minor bumps. A change in non-exported classes always is a micro bump - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: maven bundle plugin and baselining
On 11/11/14 22:54, mit_jones wrote: To clarify. I wasn't sure if you meant that the bumping of the micro version is implemented in the Eclipse plugin and also the maven-bundle-plugin or just the Eclipse plugin. I was just explaining the version bump. I'm not familiar with the bundle plugin. In bndtools, you can 'release' a bundle which will show you what to do about the version and why. -- View this message in context: http://apache-felix.18485.x6.nabble.com/maven-bundle-plugin-and-baselining-tp5010417p5010437.html Sent from the Apache Felix - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Why import version range if exact version of dependency is known?
On 12/10/14 15:15, rsteppac2 wrote: Neil, thank you for your input! First of all, you are right in that I don't have much OSGi experience in general. I understand your point about substitutable alternatives for a given API version. But in my experience, in an enterprise production environment, you don't want any of that dynamic behavior because it may lead to hard to debug application behavior if the versions of the implementations are not enforced. Anyway, I think I understood that this is against the grain of the OSGi paradigm and if I want it to be more strict, I have to deal with the more explicit configuration. Do read up on semantic versioning if you're going to do OSGi. It's such an integral part of OSGi that you can't do without. Once you've read up, you'll see your own comments in a different light ;-) Many of the OSGi devs come from 'enterprise' backgrounds. We know when you're at, you just don't get where we're at. After reading up you'll better understand that :-) Thanks! Ralf -- View this message in context: http://apache-felix.18485.x6.nabble.com/Why-import-version-range-if-exact-version-of-dependency-is-known-tp5010123p5010129.html Sent from the Apache Felix - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: maven-bundle-plugin: suppress uses directive
Why would you want to do that? On 09/10/14 14:44, stz.randh...@extaccount.com wrote: Hello, I am wondering how to tell maven-bundle-plugin to NOT calculate the uses directives for the exported packages. Instead of Export-Package: com.abcde;uses:=com.;version=1.2.3 I want to get Export-Package: com.abcde;version=1.2.3 Is this possible? Thanks. If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: OSGi and Git - what release process, how many repos?
For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Building better OSGi applications
On 17/07/14 10:04, Bulu wrote: Hi all I'm building an application on an embedded system which will contain ~20 bundles. There are many dependencies of services - say for example to provide its service, module A (several classes) needs services B,C,D. In order to fully account for the dynamics of OSGi, I have to monitor B,C,D to stop A when any of these 3 goes away. This unregisters service A, which in turn will disrupt all clients of A. If additionally you want to handle part case (A should still provide a reduced service, if only B and C are available but not D) it gets messy rapidly. In the end, I realize that I am mostly writing life cycle code instead of business logic and I have lots of OSGi dependencies, with the BundleContect passed around nearly everywhere. This smells like bad design. Could you share insights or recommend reading on how to structure OSGi services for cohesion and modularity, to avoid the problems above? Are there ways to reduce the boiler plate? Should I be investigating declarative services, iPojo or others (in general I prefer writing code than XML...). As this is an embedded system, should I be worried about the performance impact of DS? I'd suggest that you look into Declarative Services (DS). It's model is very straightforward and it reduces your boilerplate to almost zero. I tend to use it for almost all my bundles. Take a look at the bndtools tutorial for a quick start. Thanks for your insights Philipp - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Planed Felix packages
On 30/04/14 11:05, Bulu wrote: Dear all I want to use Servlet 2.6/3. The current Felix (all-in-one) HTTP bundle exports servlet 2.5. Is a release planed which supports servlet 2.6/3? Also I would like to use ServiceTracker with generics. The osgi.compendium from Felix (v. 1.4.0) doesn't support generics (as far as I can tell). Is an update release planned for this? You can compile against osgi.cmpn = 4.3.1 for this As OSGi bundles are fully interoperable - should I just run the eclipse equivalents of the above on my Felix framework? Thanks Philipp - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: OBR, bundle fragments and native code
On 29/03/14 08:47, Benoît Thiébault wrote: Hi everyone, I’m willing to simplify my application deployment and plan to use an OBR. On this OBR, I have deployed several bundles, including some containing native code. I have a cross-platform bundle, say org.example.nativelib and one fragment for each platform: - org.example.nativelib.linux64b - org.example.nativelib.linux32b - org.example.nativelib.win7-64b - org.example.nativelib.osx64b - etc. How can I be sure that when deploying org.example.nativelib from the OBR, the native fragment of the correct platform will be deployed? Include them in the bundle itself. An example from my jnotify project: Bundle-NativeCode: lib/linux/i686/libjnotify.so;osname=Linux;processor=x86,\ lib/linux/x86_64/libjnotify.so;osname=Linux;processor=x86-64 -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: OBR, bundle fragments and native code
On 29/03/14 10:35, Beno�t Thi�bault wrote: Hi and thanks for your answer. Putting everything in one bundle doesn't sound very modular... I would like each deployment to include only what is necessary for it to work... Isn't it possible? How is it not modular? I'd say it's very modular because the platform specific parts that your bundle needs to work are included. Which makes your bundle deployable on all platforms. Right now your deployment needs all kinds of special things to account for the platforms, you have different deployments... I'd that _that_ is not very modular. There are more perspectives on issues like these. I'd go with simplicity every time. Do not optimise for size/speed/whatever until you have simplicity. A best-practice is to have a bundle that includes all native libs and just implements an abstracted API, with the java op top of the libs as thin as possible. Then have a generic bundle use that first bundle (as a service) Le 29 mars 2014 10:27, Ferry Huberts maili...@hupie.com a écrit : On 29/03/14 08:47, Benoît Thiébault wrote: Hi everyone, I’m willing to simplify my application deployment and plan to use an OBR. On this OBR, I have deployed several bundles, including some containing native code. I have a cross-platform bundle, say org.example.nativelib and one fragment for each platform: - org.example.nativelib.linux64b - org.example.nativelib.linux32b - org.example.nativelib.win7-64b - org.example.nativelib.osx64b - etc. How can I be sure that when deploying org.example.nativelib from the OBR, the native fragment of the correct platform will be deployed? Include them in the bundle itself. An example from my jnotify project: Bundle-NativeCode: lib/linux/i686/libjnotify.so;osname=Linux;processor=x86,\ lib/linux/x86_64/libjnotify.so;osname=Linux;processor=x86-64 -- Ferry Huberts - 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 -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: How to use a service immediately after its activation?
On 19/03/14 12:25, Bertrand Delacretaz wrote: Hi, On Tue, Mar 18, 2014 at 10:22 PM, Neil Bartlett njbartl...@gmail.com wrote: ...Whatever you're trying to do in your special listener, wouldn't it be better done inside the same bundle as the service?... You're right, and this is similar to what Bruce suggests - the bundle's initialization code can look for initializer services using a whiteboard pattern, and call them before making the actual service available. To answer Marcel's question about the use case, the app in question is Sling-based and uses a content repository service. When upgrading the app you might need to make some changes to the content before the new version of the app starts working with the content repository. So yes, I would suggest to detect such a need in the activator, start a background job to do it (keep the activator short-lived) and only publishing the service once the content modifications are complete. You might even want to proxy your content repo to shield its implementation from upgrade concerns. making this part of the content repository service design makes absolute sense. David B's hooks suggestion also looks interesting, as a generic way of talking to services early in the setup phase. Thanks everybody for the pointers! -Bertrand - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Bad BundleSymbolicName in generated Manifest
I just tried it in the latest bndtools, which uses bnd latest (2.3) and there it works ok. Bundle-SymbolicName: org.energy-home.jemma.osgi.ah.zigbee.appliances.generic.long.name.that.will.really.wrap.in.the.manifest;singleton:=true results in Bundle-SymbolicName: org.energy-home.jemma.osgi.ah.zigbee.appliances.gen eric.long.name.that.will.really.wrap.in.the.manifest;singleton:=true so bnd seems to do it ok. therefore I would suspect the bundle plugin itself On 12/12/13 09:44, Ivan Grimaldi wrote: Hi, thanks for your reply, but if you look more carefully at the examplke I provided, you'll see that the problem is not that the symbolic name is equal to the artifactId (I want it to be like this). The generated symbolic name is being splitted in two lines with an invalid second line containing only eric (i think is the suffix of generic): so the manifest is invalid! You can take a look at the generated manifest here: http://pastebin.com/sBzK65gR Check out row #11 and row #12. I'm pretty sure this is a Felix Bundle Plugin bug... Best regards, Ivan Grimaldi Il 12/12/2013 06:38, Chetan Mehrotra ha scritto: Have a look at Maven Bundle Plugin docs around how it computes the Bundle-SymbolicName by default [1]. So in your case it defaults to artifactId (see point 4 under Bundle-SymbolicName) Chetan Mehrotra [1] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html#ApacheFelixMavenBundlePlugin%28BND%29-DefaultBehavior On Mon, Dec 9, 2013 at 3:56 PM, Ivan Grimaldi grima...@ismb.it wrote: Hi, I'm experiencing a problem using felix bundle plugin v2.4.0 and maven v3.1.1: the generated manifest for project with long names contains invalid entry for BundleSimbolicName like: Bundle-SymbolicName: org.energy-home.jemma.osgi.ah.zigbee.appliances.generic;singleton:=true eric It is possible to check out the problem by getting the code on a specific branch on github: https://github.com/ismb/jemma/tree/namingFix The affected progject is in the folder jemma.osgi.ah.zigbee.appliances.generic. Does anybody know what is wrong? Is it a bug of Felix Bundle plugin or a configuration error? Best regards, Ivan Grimaldi -- Ivan Grimaldi Istituto Superiore Mario Boella (ISMB) via P.C. Boggio, 61 - 10138 Torino (ITALY) Tel: (+39) 011 2276 505 - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Felix http service, whiteboard, DS and HttpContext
- 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 *** DISCLAIMER *** This message, including attachments, is intended solely for the addressee indicated in this message and is strictly confidential or otherwise privileged. If you are not the intended recipient (or responsible for delivery of the message to such person) : - (1) please immediately (i) notify the sender by reply email and (ii) delete this message and attachments, - (2) any use, copy or dissemination of this transmission is strictly prohibited. If you or your employer does not consent to Internet email messages of this kind, please advise Myriad Group AG by reply e-mail immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by Myriad Group AG unless otherwise indicated by an authorized representative independent of this message. ?B딮KKKCB* ??[�?쒁�X셁??K[XZ[?�?\?�?[�?쒁�X셆?�[?^?�\?X?K�??‘�??Y??]?[?[??栢 [X[�???K[XZ[?�?\?�??[???�[?^?�\?X?K�?? *** DISCLAIMER *** This message, including attachments, is intended solely for the addressee indicated in this message and is strictly confidential or otherwise privileged. If you are not the intended recipient (or responsible for delivery of the message to such person) : - (1) please immediately (i) notify the sender by reply email and (ii) delete this message and attachments, - (2) any use, copy or dissemination of this transmission is strictly prohibited. If you or your employer does not consent to Internet email messages of this kind, please advise Myriad Group AG by reply e-mail immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by Myriad Group AG unless otherwise indicated by an authorized representative independent of this message. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: BND not re-creating JAR on resource change, shows (not modified)
On 18/10/13 09:12, Stijn de Witt wrote: Hi all, We have been building our OSGi bundle WAR's with BND and this is mostly working well. But I have one small gripe and that is that BND seems to only monitor JAVA files for changes when it decides whether or not to recreate the bundle JAR. If I only change, say an HTML file or properties file in my bundle project, then when running BND it will print something like: [bnd] # my.example.bundle (example_bundle.jar) 27 (not modified) If I then proceed to 'touch' a Java file in that same project, it does build a new bundle JAR and prints something like: [bnd] # my.example.bundle (example_bundle.jar) 27 This is very tricky, because before you know it you will be testing a bundle that just was not updated, wondering why the heck it does not work. So I taught myself to always check the output for the '(not modified)' warning sign... However maybe there is a much better way to make BND check for resources also when deciding whether to build a new JAR or not? Does anyone here know? Any help greatly appreciated, -Stijn Sorry if I am wrong here, but I understood BND questions are often sent to (and answered on) this list and that BND does not have it's own list. If I'm wrong and this is offtopic, please forgive me and point me to the correct place... bnd issues (so no maven bundle plugin issues) can be discussed and reported at bndtools-us...@googlegroups.com code is at https://github.com/bndtools/bnd -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: How-To: Wait until all DS are registered
So the JSON configuration is the only place where you know which services must be registered? Then maybe the following will work. - create a 'meta' component that is a servicetracker - get the relevant JSON configuration into it so that it knows which services must be available. - register a 'meta' service once all tracked services are available, unregister when either one of those becomes unavailable - make your application have a mandatory dependency on the 'meta' service. On 28/08/13 10:32, Roland wrote: Hello David! Thank you for the quick reply David Jencks wrote If you have an unknown number of services how, conceptually, can you know when all of them are registered? This is my problem. The only one which has the required information, is the SCR. If not all factories (DS) have been registered, the JSON-configuration can not be deserialized. David Jencks wrote If you actually do know which services a client needs then the simplest solution is to make the client a DS component with mandatory references to the services it needs. When the client shows up, you can be sure all the services it needs are available. This is a good idea, but I want to keep the system stupid. Thus, I don't want to define which DS (factory) is required. Dependencies must emerge from the JSON-configuration. But, I have a sixth idea: I could prove if all components are in state STATE_ACTIVE. But It may happen that all components are in state STATE_ACTIVE but some component-descriptions are still not considered. When does the SCR notice that a component has to be added? -- View this message in context: http://apache-felix.18485.x6.nabble.com/How-To-Wait-until-all-DS-are-registered-tp5004727p5004730.html Sent from the Apache Felix - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Maven
On 22/08/13 09:07, Dawid Loubser wrote: Ah, I didn't even know that BND Tools (used from ant) put in a - non-standard and meaningless, as you say - Private-Package manifest entry in the JAR. I can see how that would confuse the original poster coming from there, then. Impedance mismatch or not, we are running a very large (many bundles) supplier integration system on OSGi, built and tested with maven, using strong design-by-contract and test-driven-development practices. The amount of code and complexity in relation to development team size is staggering, and I wouldn't dream of doing it without Maven! Then just wait until we have our Gradle build changes complete in bndtools... Spoiler: From what we now see the build is sped up somewhere between 5x-10x compared to the ant build. -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Invalid package name: '*' ????
On 21/06/13 15:28, Roland wrote:
hello,
I'm at it again and I hope I'm right here.
I hang on a problem for a few hours. I do not know what I'm doing wrong.
Below is the error message and my POM.
...
[INFO] [bundle:bundle {execution: default-bundle}]
in default pack?
[WARNING] Bundle mygroupId:myartifactId:bundle:1.0.0.0 : Invalid package
name: '*'
[ERROR] Bundle
de.ids.acos.rtu.osgi.bundles:acos-rtu-constants:bundle:1.0.0.0 : The default
package '.' is not permitted by the Import-Package syntax.
This can be caused by compile errors in Eclipse because Eclipse creates
valid class files regardless of compile errors.
The following package(s) import from the default package null
[ERROR] Error(s) found in bundle configuration
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
parent
groupIdmygroupID/groupId
artifactIdmyparent/artifactId
version1.0.0.0/version
/parent
groupIdmygroupID/groupId
artifactIdmyproject/artifactId
namemyproject/name
packagingbundle/packaging
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
extensionstrue/extensions
configuration
archive
/archive
instructions
Bundle-SymbolicName${project.groupId}.${project.artifactId}/Bundle-SymbolicName
Bundle-Description${project.description}/Bundle-Description
Bundle-Version${project.version}/Bundle-Version
Bundle-Activator/Bundle-Activator
EXPORT-PACKAGE
mypackage;version=1.0.0.0
/EXPORT-PACKAGE
IMPORT-PACKAGE
*
/IMPORT-PACKAGE
I'm not a maven user, but try without the import-package section.
bnd calculates this for you.
/instructions
/configuration
/plugin
/plugins
/build
/project
I have already tried mvn clean, but that does not help. Recently I get
frequently strange error messages from maven. From time to time I can not
build my projects and I get the following error message: ... Source not
found. This indicates that the compiler can not find the source. After a
further try everything works again! There is probably a bug somewhere in the
Maven-Universe. Maybe I should ask this in a Maven forum.
Any suggestions?
Thanks in advance!
Roland
--
View this message in context:
http://apache-felix.18485.x6.nabble.com/Invalid-package-name-tp5004065.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
Ferry Huberts
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: Invalid package name: '*' ????
On 21/06/13 17:47, Roland wrote: But in all other projects of mine are like this and are ok. Why not this project? the bundle plugin was recently updated. it contains a much newer bnd. that bnd probably is much stricter. did you rebuild all of these other projects? if not, then do so to support your claim ;-) -- View this message in context: http://apache-felix.18485.x6.nabble.com/Invalid-package-name-tp5004065p5004079.html Sent from the Apache Felix - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Declarative Services
On 20/06/13 10:44, bokie wrote: Hi David, Thanks for taking the time to respond. I'll try to illustrate the use case with a small diagram... ___ ______ | | | | | Consumer | | (B) requires | | Service (s) |--| Registry |-- |(a) || instance (a) | |__ | |___| |__| |___| Summarizing the problem: Assuming that (B) and Consumer (a) of Service (s) are in the same bundle, how should (B) acquire the instance (a) instantiated by the SCR? several possibilities, which depend on use-case and taste 1. You can let the consumer register itself as a service, so that B can get it from the registry 2. You can use the whiteboard pattern to let the service s retrieve a/all consumer/s from the registry. B can then do the same. 3. You could merge B and the consumer since B always requires an (the?) instance of consumer a 4. ... (it goes on) ... Thanks again, Jorge -- View this message in context: http://apache-felix.18485.x6.nabble.com/Declarative-Services-tp5004036p5004044.html Sent from the Apache Felix - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Bndtools 2.1 Released
Bndtools 2.1 Released Bndtools: The easy, powerful and productive way to develop with OSGi. Based on bnd and Eclipse. We just released version 2.1. We're very proud of it and are convinced that it will make your life as an OSGi developer much easier. Easier than any other tool around. All together we believe that Bndtools is now the foremost tool for developing OSGi applications, and continues our mission to make OSGi development easier and more productive than traditional Java development. We've been tuning our development flow so that we can do releases on a shorter schedule and it seems to be working: it's been 11 weeks since the release of 2.0. This new version has many improvements that - not only - make it faster again, but also expand the functionality to offer a more complete experience. We've focused on bug fixes with an increased attention to details and also added some new functionality. A brief overview of some noteworthy changes: * You can now specify command line arguments on the Run tab, which enables running/debugging in Eclipse with exactly the same arguments as in the bug report that one of your users just reported :-). For more details, see https://github.com/bndtools/bndtools/wiki/Program-Arguments. * Bndtools will now (by default) generate .gitignore files when you create new Bndtools projects so that you don't commit derived files. This can be switched of in the Bndtools preferences panel. * The JAR viewer now by default opens the manifest file and also remembers the selected file so that when the JAR is updated, it will reload the JAR and select that file again. * Bndtools now (finally) fully supports paths containing whitespace. This was a long standing bug that affected launching from Bndtools. See also the notes below. * A compiler error is now generated on incorrect usage of the @Reference annotation. An example: you have a setter (e.g. add) for a dynamic dependency, but no unsetter (e.g. remove). * We again improved the build speed. Of course there are many more gems in the changes. A full list of changes can be found on our wiki: https://github.com/bndtools/bndtools/wiki/Changes-in-2.1.0. Important Notes: * We're deprecating running from *.bnd files, which is why we're no longer showing the 'Run Requirement/Resolve' panel on the Run tab. Users are strongly advised to migrate their run settings into *.bndrun files. Expect the Run tab to be removed completely for *.bnd files in a future release. * Existing workspaces should update their cnf/buildrepo/biz.aQute.launcher to version 1.0.6 to fix issues with paths containing whitespace. Download it here https://bndtools.ci.cloudbees.com/job/bnd.master/72/artifact/dist/bundles/biz.aQute.launcher/biz.aQute.launcher-1.0.6.jar, or generate a new cnf project by removing the existing one. Installation: You can install Bndtools into Eclipse through the marketplace or use our Eclipse update site, see http://bndtools.org/installation.html for further instructions. For those of you that want to live on the (bleeding) edge, our latest stable build lives here: https://bndtools.ci.cloudbees.com/job/bndtools.master/lastSuccessfulBuild/artifact/bndtools.build/generated/p2/ As usual, please report any issues you find on our Github bug tracker: https://github.com/bndtools/bndtools/issues -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Bndtools 2.1 Released
On 26/04/13 15:55, Tang Yong wrote: Ferry, Great news! I have a question about bndtools. For some large projects(eg.glassfish), such project is mostly made up of many modules which are built using maven pom files. Whether bndtools supports loading such projects *automaticlly* into bndtools perspective rather than manually re-adjusting project's structure and can rightly recognise modules's dependencies? As long a you comply to the bnd workspace layout it should all work just fine. If not, we'd like to hear from you! The bnd workspace layout prescribes that all projects are side by side in a directory that also has the cnf project. Ferry Thanks --Tang Ferry Huberts wrote: Bndtools 2.1 Released Bndtools: The easy, powerful and productive way to develop with OSGi. Based on bnd and Eclipse. We just released version 2.1. We're very proud of it and are convinced that it will make your life as an OSGi developer much easier. Easier than any other tool around. All together we believe that Bndtools is now the foremost tool for developing OSGi applications, and continues our mission to make OSGi development easier and more productive than traditional Java development. We've been tuning our development flow so that we can do releases on a shorter schedule and it seems to be working: it's been 11 weeks since the release of 2.0. This new version has many improvements that - not only - make it faster again, but also expand the functionality to offer a more complete experience. We've focused on bug fixes with an increased attention to details and also added some new functionality. A brief overview of some noteworthy changes: * You can now specify command line arguments on the Run tab, which enables running/debugging in Eclipse with exactly the same arguments as in the bug report that one of your users just reported :-). For more details, see https://github.com/bndtools/bndtools/wiki/Program-Arguments. * Bndtools will now (by default) generate .gitignore files when you create new Bndtools projects so that you don't commit derived files. This can be switched of in the Bndtools preferences panel. * The JAR viewer now by default opens the manifest file and also remembers the selected file so that when the JAR is updated, it will reload the JAR and select that file again. * Bndtools now (finally) fully supports paths containing whitespace. This was a long standing bug that affected launching from Bndtools. See also the notes below. * A compiler error is now generated on incorrect usage of the @Reference annotation. An example: you have a setter (e.g. add) for a dynamic dependency, but no unsetter (e.g. remove). * We again improved the build speed. Of course there are many more gems in the changes. A full list of changes can be found on our wiki: https://github.com/bndtools/bndtools/wiki/Changes-in-2.1.0. Important Notes: * We're deprecating running from *.bnd files, which is why we're no longer showing the 'Run Requirement/Resolve' panel on the Run tab. Users are strongly advised to migrate their run settings into *.bndrun files. Expect the Run tab to be removed completely for *.bnd files in a future release. * Existing workspaces should update their cnf/buildrepo/biz.aQute.launcher to version 1.0.6 to fix issues with paths containing whitespace. Download it here https://bndtools.ci.cloudbees.com/job/bnd.master/72/artifact/dist/bundles/biz.aQute.launcher/biz.aQute.launcher-1.0.6.jar, or generate a new cnf project by removing the existing one. Installation: You can install Bndtools into Eclipse through the marketplace or use our Eclipse update site, see http://bndtools.org/installation.html for further instructions. For those of you that want to live on the (bleeding) edge, our latest stable build lives here: https://bndtools.ci.cloudbees.com/job/bndtools.master/lastSuccessfulBuild/artifact/bndtools.build/generated/p2/ As usual, please report any issues you find on our Github bug tracker: https://github.com/bndtools/bndtools/issues -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Creating OSGI bundles to provide dependency resolution in eclipse p2 repositories
On 02/04/13 14:56, Robert Gründler wrote: isn't maven-bundle-plugin just a maven plugin wrapping bnd? yes it is. We have a similar issue with bndtools: When we create a wrap project, we can build the bundle just fine. but we can't convince Eclipse to import from that bundle. We're thinking on how to work around/fix this but we haven't found a solution so far. The workaround for us so far has been 1 of these 2 solutions: 1- put the generated 'wrap' bundle in a repository and use it from there 2- extract the sources from the 'wrap' bundle and put them in the src folder of the project -robert On Tue, Apr 2, 2013 at 2:52 PM, Tribon Cheng tribon1...@gmail.com wrote: why not to use bnd? On Tue, Apr 2, 2013 at 8:37 PM, Robert Gruendler r.gruend...@gmail.com wrote: Hi all, I'm working on a couple of eclipse plugins which have dependencies to 3rd party libraries. Some of those libraries are not available as OSGI bundles, so i need to wrap them in OSGI bundles manually. I've created a maven project [1] which uses the maven-bundle-plugin to embed the maven dependencies in the generated bundle. This works fine when building the project in the commandline, but in eclipse i'm experiencing this odd behavior: 1. The bundle can be resolved properly 2. When importing classes from the 3rd party library embedded in the bundle, i'm gettting the following Error in eclipse: Cannot find the class file for org.json.simple.parser.ParseException where ParseException is a class from the 3rd party dependency which should be embedded in the bundle generated by the maven-bundle-plugin. Am i having just a misconfiguration here with my pom, or am i going down the wrong track to tackle this bundle? regards -robert [1] https://github.com/pulse00/osgi-repository/blob/master/simple-json/pom.xml -- Contribute to Enterprise Integration -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Creating OSGI bundles to provide dependency resolution in eclipse p2 repositories
On 02/04/13 15:18, Neil Bartlett wrote: I assume the error is seen at build-time rather than runtime? Eclipse does yes build time only not support building against bundles containing nested JARs. Even with non-nested JARs we have this issue because of 'missing' sources (not in the src folder, but in the generated bundle). Talked to you about this before and we had no solution at that time. ref: https://github.com/bndtools/bndtools/issues/579 If you think about this, it's fair enough... other Java compilers such as javac also do not support it. So even if you got this to work in Eclipse PDE, you would be unable to build your code from the command line with ANT/Maven/whatever. On Tue, Apr 2, 2013 at 2:11 PM, Ferry Huberts maili...@hupie.com wrote: On 02/04/13 14:56, Robert Gründler wrote: isn't maven-bundle-plugin just a maven plugin wrapping bnd? yes it is. We have a similar issue with bndtools: When we create a wrap project, we can build the bundle just fine. but we can't convince Eclipse to import from that bundle. We're thinking on how to work around/fix this but we haven't found a solution so far. The workaround for us so far has been 1 of these 2 solutions: 1- put the generated 'wrap' bundle in a repository and use it from there 2- extract the sources from the 'wrap' bundle and put them in the src folder of the project -robert On Tue, Apr 2, 2013 at 2:52 PM, Tribon Cheng tribon1...@gmail.com wrote: why not to use bnd? On Tue, Apr 2, 2013 at 8:37 PM, Robert Gruendler r.gruend...@gmail.com wrote: Hi all, I'm working on a couple of eclipse plugins which have dependencies to 3rd party libraries. Some of those libraries are not available as OSGI bundles, so i need to wrap them in OSGI bundles manually. I've created a maven project [1] which uses the maven-bundle-plugin to embed the maven dependencies in the generated bundle. This works fine when building the project in the commandline, but in eclipse i'm experiencing this odd behavior: 1. The bundle can be resolved properly 2. When importing classes from the 3rd party library embedded in the bundle, i'm gettting the following Error in eclipse: Cannot find the class file for org.json.simple.parser.ParseException where ParseException is a class from the 3rd party dependency which should be embedded in the bundle generated by the maven-bundle-plugin. Am i having just a misconfiguration here with my pom, or am i going down the wrong track to tackle this bundle? regards -robert [1] https://github.com/pulse00/osgi-repository/blob/master/simple-json/pom.xml -- Contribute to Enterprise Integration -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Help needed to use maven to build an osgi application
On 02/04/13 06:31, Prasad Jeewantha wrote: Hi Chetan, Thanks a lot for the response. What I want is to package all the bundles in some structure in the final distribution so that when the user extracts it and run say *sh run.sh* all the bundles will be installed into an osgi runtime. The usage of OSGi should be hidden from the user. I believe option 3 will be helpful. Thanks again, Then you can also just use the bnd export function, which is also supported by bndtools. PJ On Mon, Apr 1, 2013 at 11:47 AM, Chetan Mehrotra chetan.mehro...@gmail.comwrote: There are multiple options to achieve this. 1. Pax Runner - Use Pax Runner [1] if you want your bare bone OSGi container. See [2] for some example. It allows you to package and launch an OSGi container 2. Use existing applications like Apache Karaf to package your bundle 3. Use maven-launchpad-plugin [3] to package the bundle as part of single executable jar. This is currenly limited to supporting Felix and would not work for Equinox. See [4] as one example of this plugin in action which packages a bunch of bundles as part of an example application Chetan Mehrotra [1] https://ops4j1.jira.com/wiki/display/paxrunner/Documentation [2] http://www.jroller.com/habuma/entry/launching_osgi_with_pax_runner [3] http://sling.apache.org/site/maven-launchpad-plugin.html [4] https://github.com/apache/felix/blob/trunk/examples/jaas/launcher/pom.xml On Mon, Apr 1, 2013 at 11:16 AM, Prasad Jeewantha jeewamp@gmail.com wrote: Hi all, I am trying to build an osgi application with Maven. I am using maven-bundle-plugin and maven-scr-plugin to create the bundles. I have all the bundles created in 3 separate directories in the final distribution. What I want is to run all the osgi bundles in an OSGi container with a single command (may be using a shell script). I believe I have to create a config.ini file listing all the bundles which need to be run in the container. Is there a way to generate this file from Maven at compilation time? Or is there a better way to create the project without manually creating the configuration files? Any advice is greatly appreciated. Thanks in advance, PJ PS. I created a Stack overflow question on this topic. http://stackoverflow.com/q/15729182/1411653 -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
EclipseCon tutorial 'Mastering OSGi with Ease': slides and code
The tutorial that Neil Bartlett and I gave on EclipseCon this week, called 'Mastering OSGi with Ease', went quite well and we think we were able to provide the participants with an understanding of how easy it can actually be to develop OSGi bundles and services. The slides are available here: http://www.eclipsecon.org/2013/sessions/mastering-osgi-ease. The corresponding code is available here: https://github.com/bndtools/eclipsecon2013-tutorial. -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
EclipseCon tutorial 'Mastering OSGi with Ease': slides and code
The tutorial that Neil Bartlett and I gave on EclipseCon this week, called 'Mastering OSGi with Ease', went quite well and we think we were able to provide the participants with an understanding of how easy it can actually be to develop OSGi bundles and services. The slides are available here: http://www.eclipsecon.org/2013/sessions/mastering-osgi-ease. The corresponding code is available here: https://github.com/bndtools/eclipsecon2013-tutorial. -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Shutdown deadlock on OS X while doing AWT stuff
On 05/03/13 14:15, Dan Gravell wrote:
In my OSGi app (running on Felix 4.0.2) I use the Java SystemTray to add
items to the system tray. One of these items is a 'quit' item:
miQuit.addActionListener(new ActionListener() {
@Override
def actionPerformed(e:ActionEvent) {
platform.shutdown();
}
});
Then, PlatformImpl.shutdown does a:
Why do you delegate to 'platform'.
I think you can call bundleContext.getBundle(0).stop() right there.
See if that fixes your deadlock
Otherwise try removing the systray items before calling stop.
lastContext.getBundle(0).stop();
Where lastContext is the BundleContext for the containing bundle. The
SystemTray code and PlatformImpl are in different bundles. Stopping the
bundles has the effect of calling:
@Deactivate def shutdown() {
awt.SystemTray.getSystemTray.getTrayIcons.foreach(systemTray.remove);
}
This is back on the SystemTray component (I'm using bnd style DS here).
I am seeing a deadlock occur, but fairly infrequently and only on OS X.
I managed to get a stack trace last time. Here are two suspicious
looking threads (I attached the entire thing):
FelixStartLevel daemon prio=5 tid=109c2d800 nid=0x10f371000 in
Object.wait() [10f36e000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 7eae23890 (a java.awt.EventQueue$1AWTInvocationLock)
at java.lang.Object.wait(Object.java:485)
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1117)
- locked 7eae23890 (a java.awt.EventQueue$1AWTInvocationLock)
at java.awt.Window.doDispose(Window.java:1036)
at java.awt.Window.dispose(Window.java:974)
at apple.awt.CTrayIconPeer.disposeImpl(CTrayIconPeer.java:58)
at apple.awt.PeerImpl.dispose(PeerImpl.java:30)
at java.awt.TrayIcon.removeNotify(TrayIcon.java:701)
at java.awt.SystemTray.remove(SystemTray.java:273)
- locked 7ed5e5968 (a java.awt.SystemTray)
at
com.elsten.bliss.ui.systemtray.SystemTray$$anonfun$shutdown$1.apply(SystemTray.scala:149)
at
com.elsten.bliss.ui.systemtray.SystemTray$$anonfun$shutdown$1.apply(SystemTray.scala:149)
at
scala.collection.IndexedSeqOptimized$class.foreach(IndexedSeqOptimized.scala:34)
at scala.collection.mutable.ArrayOps.foreach(ArrayOps.scala:38)
at com.elsten.bliss.ui.systemtray.SystemTray.shutdown(SystemTray.scala:149)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
[...]
AWT-EventQueue-0 prio=6 tid=105d82800 nid=0x11505f000 in Object.wait()
[11505d000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 7ece2ed20 (a org.apache.felix.main.Main$1)
at java.lang.Thread.join(Thread.java:1210)
- locked 7ece2ed20 (a org.apache.felix.main.Main$1)
at java.lang.Thread.join(Thread.java:1263)
at
java.lang.ApplicationShutdownHooks.runHooks(ApplicationShutdownHooks.java:79)
at
java.lang.ApplicationShutdownHooks$1.run(ApplicationShutdownHooks.java:24)
at java.lang.Shutdown.runHooks(Shutdown.java:79)
at java.lang.Shutdown.sequence(Shutdown.java:123)
at java.lang.Shutdown.exit(Shutdown.java:168)
- locked 7faf9e240 (a java.lang.Class for java.lang.Shutdown)
at java.lang.Runtime.exit(Runtime.java:90)
at java.lang.System.exit(System.java:921)
at com.apple.eawt._AppEventHandler.performQuit(_AppEventHandler.java:124)
- locked 7ed6a2420 (a com.apple.eawt._AppEventHandler)
at com.apple.eawt.QuitResponse.performQuit(QuitResponse.java:31)
at
com.apple.eawt._AppEventHandler$_QuitDispatcher.performDefaultAction(_AppEventHandler.java:382)
at
com.apple.eawt._AppEventHandler$_AppEventDispatcher$1.run(_AppEventHandler.java:487)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
[...]
Is there something I'm doing incorrectly? It looks like
_AppEventHandler.performQuit is calling System.exit... but won't this
be prone to deadlocks with OSGi?
It's possible in this case that I chose to shutdown my app and this is
what sent the event. If this is the case how can I work around this? I'm
guessing that the removal of SystemTray items can't be done in this
case, or has to be done in some managed thread context.
Just wondering if anyone else has seen this.
Dan
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
Ferry Huberts
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: Very beginner question: maven, netbeans. Implementing a client....
On 12/02/13 13:21, Imóveis Nacionais wrote: Hi all, my first time [snip] How can I access server bundle interface type during compile time? put the 'server bundle' on the classpath during compile -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Very beginner question: maven, netbeans. Implementing a client....
On 12/02/13 13:21, Imóveis Nacionais wrote: Hi all, my first time I am a very new beginner in osgi and am stating with netbeans maven and felix If you're willing to use Eclipse, then bndtools might be something you'd want to try. Follow the tutorial on http://bndtools.org/tutorial.html and you'll be up in no time ;-) - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Bndtools 2.0 released!
On behalf of Neil (and the team) Bndtools 2.0 The easy, powerful and productive way to develop with OSGi. Based on bnd and Eclipse. Version 2.0 was just released, see http://njbartlett.name/2013/02/11/bndtools2-released.html. We're very proud of it and are convinced that it will make your life as an OSGi developer _much_ easier. Easier than any other tool around. It's been a big effort, 608 commits, 1132 files changed, 67199 insertions(+), 49291 deletions(-), and we're very happy it's now out there. This new version has _many_ improvements that - not only - make it _much_ faster and thus a breeze to use, but also expands the functionality to offer a more complete experience. An example is the new Export functionality that allows you to export your run configuration straight into an executable JAR that completely contains your OSGi application, including the framework and the launcher! You can install Bndtools into Eclipse through the marketplace or use our Eclipse update site at http://bndtools-updates.s3.amazonaws.com/ (see http://bndtools.org/installation.html#update-site). For those of you that want to live on the (bleeding) edge, our latest stable build lives here: https://bndtools.ci.cloudbees.com/job/bndtools.master/lastSuccessfulBuild/artifact/bndtools.build/generated/p2/ As usual, please report any issues you find on our Github bug tracker: https://github.com/bndtools/bndtools/issues -- Ferry Huberts - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
