Re: Felix + Gemini JPA issue?
Even when I think I would not use dot instead of slash, I think there
is something in the spec open to interpretation.
3.9 reads
The following sections define the factors that influence the runtime
class loading and then define the exact search order the Framework
must follow when a class or resource is loaded.
And then 3.9.1 (entitled Bundle Class Path) reads
The dot ('.' \u002E) container path is a synonym for slash ('\') or
the root of a container. [...]
Now, this is in a section that in about to introduce the concept of
bundle class path (so it is not clear that this applies in other
contexts outside of of a bundle class path definition), but at the
same time it talks about container path (that would imply that this
is more generic and involves al resource resolutions).
At the end of the day, I think Richard is right and a slash should be
used to conform to a more strict interpretation, but at the same time
I cannot say that what Equinox does is wrong by understanding path in
the more relaxed interpretation.
-lucas
On Apr 16, 2012, at 11:35 PM, Michael Van Geertruy
mvangeert...@comcast.net wrote:
What's saddest about this is the Equinox is supposed to be the reference
implementation of the spec. The fact that this bug exists is, in itself,
highly problematic.
On 4/16/2012 3:33 PM, Richard S. Hall wrote:
On 4/16/12 15:10 , Michiel Vermandel wrote:
Hi,
I am experimenting with Felix and Gemini JPA.
I encounter an issue when I
useexclude-unlisted-classesfalse/exclude-unlisted-classes in the
persinstence.xml.
The Gemini JPA example then produces a nullpointer exception.
java.lang.NullPointerException
at
org.eclipse.gemini.jpa.provider.BundleArchive.getEntries(BundleArchive.java:87)
In the BunldeArchive.getEntries they use the current bundle to get all
.class entries in this way:
entries = bundle.findEntries(.,*.class, true);
If I try that myself - for example in the start method of the bundles
activator, this statement produces a null object.
however entries = bundle.findEntries(/,*.class, true);
produces a enumerator with all class files.
Could it be that Eclipse Equinox produces a valid entries list with
findEntries(. and Felix requires findEntries(/ ?
Looks like that is the case. The spec says this:
10.1.6.13 public EnumerationURL findEntries ( String path , String
filePattern , boolean recurse )
path - The path name in which to look. The path is always relative to the
root of this bundle and may begin with /. A path value of / indicates
the root of this bundle.
It looks like the Gemini guys rely on non-standard behavior provided by
Equinox, at least according to my interpretation of the spec. Perhaps you
should file a bug against Gemini and ask them to use /.
- richard
Any ideas how to solve this?
Thanks a lot!
-
http://www.codessentials.com - Your essential software, for free!
Follow us at http://twitter.com/#!/Codessentials
-
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
Issues while updating gogo bundles
Hi, It looks like there are some issues while refreshing gogo bundles This is what you get when updating gogo runtime Welcome to Apache Felix Gogo g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (4.0.2) 1|Active |1|Apache Felix Bundle Repository (1.6.6) 2|Active |1|Apache Felix Gogo Command (0.12.0) 3|Active |1|Apache Felix Gogo Runtime (0.10.0) 4|Active |1|Apache Felix Gogo Shell (0.10.0) g! update 3 g! Welcome to Apache Felix Gogo g! lb gosh: java.lang.IllegalStateException: session is closed gosh: stopping framework [here, the framework stops] And this is when updating gogo shell Welcome to Apache Felix Gogo g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (4.0.2) 1|Active |1|Apache Felix Bundle Repository (1.6.6) 2|Active |1|Apache Felix Gogo Command (0.12.0) 3|Active |1|Apache Felix Gogo Runtime (0.10.0) 4|Active |1|Apache Felix Gogo Shell (0.10.0) g! update 4 g! Welcome to Apache Felix Gogo g! lb gogo: CommandNotFoundException: Command not found: l g! gogo: CommandNotFoundException: Command not found: b g! [here the shell is very close to unusable] Are these bundles meant to ever be refreshed? Regards, Lucas - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Exposing/Including dependencies to/in Bundles
Hi, On Mon, Feb 27, 2012 at 4:45 PM, David G. davidjgonza...@gmail.com wrote: Quick question about including/exposing dependencies for bundles running under felix. As I understand it, there are predominantly 2 ways of exposing 3rd party libs for use in our bundle: 1) Include the 3rd party jar files in the bundle's /lib folder - which exposes all packages of the jar(s) to the code in the bundle. Just to add to what Richard pointed out, there is no need to export these external libs. 2) Package the 3rd party jar/jars as an OSGi bundle, exporting the requisite packages in the bnd by way of the manifest. I seems like the first strategy encourages potential for future conflicts (if another bundle exports the same packages) but reduces the dependencies for the bundle, since its self-contained. Here I agree with Richard, I do not see how this causes future conflicts. The second strategy allows for reusability of code (all bundles that need 3rd party library X can get the dependencies for the same bundle) however this adds extra dependencies to the bundle deployment lifecycle (you may have ensure that when Bundle A is deployed, there is process in place to deploy 3rd party bundles X, Y and Z). - Thoughts around when to use one over the other? In a perfect OSGi world, the later approach is best, unluckily for us, we are not in that world. Here is where my experience differs from the experience Richard had. We found that if we always aim for the later approach we see two issues. (1) We go into a bundle-boom effect where we end up with many bundles and it is very hard to know what depends on what without a very high diligence and being sure that we do not have superfluous bundles takes a lot of time, and (2) if we have to work with legacy libraries that expect a single class loader that has it all, then the former approach makes everybody's life a lot easier. - Are there any other dangers to using either method I didn't outline above? Here I agree with Richard, both ways work well, but there is no one size fits all approach. You can mix and match both approaches as needed. - Any other options? When we go for the later approach, we try to keep everything into two types of bundles. (1) Bundles that just expose the interface to a service, and (2) bundles that export as few packages as possible and all the services definitions are declared thru DS (and, if possible, we export no package and only import the definition from the services we want to expose) Just to be clear, we do know that this approach does use more memory, does not allow for class loader short circuits and the class loader has to work more (once). Regards, Lucas Thanks -- David Gonzalez Sent with Sparrow (http://www.sparrowmailapp.com/?sig) - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Could not create framework :java.lang.NoClassDefFoundError:org/osgi/framework/launch/Framework ?
Hi, In a strict sense, if you include osgi.core.jar v4.3, then you will fix this, but this is embedded inside the felix framework jar. What version of Felix are you using? Regards, Lucas On Mon, Jun 20, 2011 at 8:10 AM, Gaetan Abessolo g.abess...@netvisio.com wrote: Could not create framework :java.lang.NoClassDefFoundError:org/osgi/framework/launch/Framework ? how to solve this problem ? - 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
Re: Implementing the OSGi logging service
Just a note, even when the approach you are following to have a Log Service implementation that uses SLF4J would work, the overall strategy would be wrong. It is a cleaner implementation to keep the existing Log Service and create a bundle that registers a LogListener that sends the LogEntry to SLF4J. Regards, Lucas On Tue, Jun 7, 2011 at 5:07 PM, Richard S. Hall he...@ungoverned.org wrote: On 6/7/11 15:52, Christopher BROWN wrote: Thanks Richard. I'd tried looking at the OSGi alliance, just saw docs and specs... Anyway followed your advice, seems fine, so I'm assuming all that remains to be done is to extract the org.osgi.service.log classes from the JAR and rebuild the MANIFEST.MF to reflect the API export and build my implementation. Just to be clear, the JAR file includes the source files too, so you can just copy them into your project if you want, not merely the classes. - richard Will get on with that now :-) -- Christopher On 7 June 2011 21:20, Richard S. Hallhe...@ungoverned.org wrote: On 6/7/11 15:09, Christopher BROWN wrote: Hello, I chose Felix to add embedded OSGi capabilities to an existing host application, and am happy with that choice. The host application already uses a logging framework (SLF4J with Logback Classic as the bound implementation), so I exported the SLF4J API -- not the Logback implementation -- using system packages extra and that's fine too. However, I'd like to provide an implementation of the standard OSGi logging service APIs that delegates logging to SLF4J so that I can hide that implementation choice a bit more. The felix logging implementation bundle includes both the API and the Felix implementation. My question is: where can I get the logging API without the Felix implementation? I'd like to get it from the same source as Felix, without having to hack at the Felix bundle to strip out the implementation that isn't necessary in my situation. Just download the org.osgi.compendium JAR file from the Maven repo, it contains the source code as well as the class files. You can also get it directly from the OSGi Alliance. - richard Thanks, Christopher - 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
Low ports and non-root
Hi all, In an application we are developing we need to open low ports and run as another user with lower permissions than root. To do this we have plan to - Start Felix as root - Have a bundle with native bindings that knows when all the required ports are open - This native bundle will then change the current user from root to the right one The problem we have is that the application will need a full restart to update the bundle that serves the web app. The question we are facing is that just like any other resource, a server socket is something that should be opened once (by one bundle or the framework itself) and given to the specific bundle that needs it, do you know if there is any such an effort to make any of the current standard bundles work this way? I know there are many workarounds possible, but it just feels natural for the server socket resource to be provided as a service that the Http Service (or any other service that needs a server socket resource) requests. I also know that an update on this other bundle will imply a restart, but I think an update here would be unusual at best. Regards, Lucas - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
EventAdmin
Hi All, I am trying to figure out how EventAdmin actually works. Is it possible for an EventAdmin implementation to call an EventHandler::handleEvent while this handler is processing another event by another thread? Is this different if the event is synchronous or asynchronous? And if the event that is waiting to be processed was triggered by the same EventHandler? Regards, Lucas - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
OSGi and Jaas (Authentication)
Hi All, I am working on a project were we are trying to prototype the exposure of some of Jaas functionality in an OSGi way. For the authentication part, the requirement was the following: - You should be able to authenticate users using the current Jaas mechanism e.g. LoginContext ls = new LoginContext(name,...); lc.login(); - There has to be a mechasnism to define new LoginModule(s) and bind a new AppConfigurationEntry[] to a login context name. - There should be a mechanism to bind a LoginModule to a realm. - There should be a mechanism to define new realms. The approach was the following: - Bundle 1: . Defines an interface so new bundles can define a new AppConfigurationEntry[] and bind it to a name (defining a new OSGi service). . Defines the interface for a realm. . Overrides the default Configuration with a new implementation that looks for the service that specifies an AppConfigurationEntry[] for a given name. - Bundle 2: . Implements a new LoginModule, the binding of this LoginModule is done using the configuration admin service. . Specifies a new AppConfigurationEntry[] (this may be done in another bundle). - Bundle 3: . Defines the realm - Bundle 4 . Performs the login. Now LoginContext performs the following to load the LoginModule (slightly simplified) contextClassLoader = Thread.currentThread().getContextClassLoader() c = Class.forName(loginModuleName, true, contextClassLoader); constructor = c.getConstructor(...); module = constructor.newInstance(...); So, to make this work, we need to force Bundle 4 (and every bundle that performs a login) to execute Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader()) before performing the login and to have Dynamic-Import: * Is there a better way for this? Is this the standard pattern to work around this specific issue? It looks like asking dynamic import * and asking to setup the classloader is asking for too much. Regards, Lucas PS: I will post the questions we had on the authorization part of Jaas into another email as the use cases are more complex. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Felix and Fragments
Hi All, Once we get the next release (1.6.0) out, I will once again try to make some time to further this part of the implementation. - richard Is there a roadmap that has a (tentative) feature/release at the site? The feature that I would like to know if/when it will be implemented is boot classpath extensions (and I do know that this cannot be implemented in a portable way). Thanks, Lucas - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Bundle update not following the spec?
Thanks Richard. It is perfect! On Tue, Jun 24, 2008 at 5:25 PM, Richard S. Hall [EMAIL PROTECTED] wrote: Lucas, I updated the FAQ, does it make more sense now? http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+OSGi+FAQ#ApacheFelixOSGiFAQ-WhenIupdatemybundle%2Cwhyaremybundle%27soldclassesstillbeingused%3F - richard Lucas Galfaso wrote: Hi, The standard also reads quote 4.3.10 Updating Bundles [...] The update process supports migration from one version of a bundle to a newer version of the same bundle. The exports of an updated bundle must be immediately available to the Framework. If none of the old exports are used, then the old exports must be removed. Otherwise, all old exports must remain available for existing bundles and future resolves until the refreshPackages method is called or the Framework is restarted. /quote Now, this is somehow different from what http://cwiki.apache.org/FELIX/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-ApacheFelixOSGiFrequentlyAskedQuestions reads, this may not be too bad as you may say that the wiki is just slightly incomplete. Just as I said, not Not too bad. Why is it incomplete? The wiki reads (cut some cutpaste to make it clearer) 1. Your bundle does not export any packages. - The updated classes should become available immediately. 2. Your bundle exports some packages, but does not import those same packages. - The updated classes should become available immediately. - However other bundles using the exported packages from the updated bundle will not start using the new classes until PackageAdmin.refreshPackages() is called (this can be invoked in the Felix shell using the refresh command). 3. Your bundle exports some packages and also imports those same packages (see the importing and exporting FAQ below). - Neither the updated bundle nor any bundles importing packages from the updated bundle will see any updated classes until the packages are refreshed. 1. If no bundle is wired to the old module by the use of an import or dynamic import.* - The updated classes should become available immediately. - The old module will be removed and cannot be used to resolve a bundle. * Note: If your bundle does not export, then no bundle can create a wire to it. 2. There is a bundle wired to old module by the use of an import or dynamic import (this bundle may be the same bundle being updated). - Existing wires to this bundle will not start using the new classes until PackageAdmin.refreshPackages() is called. - The old module will remain and may be used to resolve a bundle until PackageAdmin.refreshPackages() is called. - New bundles and bundles that are updated may use the new or old module of the updated bundle. - All bundles using dynamic import may pick the new or old module of the updated bundle when creating a new wire. Is the above right? Even if the above is right, I think that using a simpler wording is better as a simplified interpretation of the FAQ may be after you update a bundle, execute a refresh and this is what 90% of the users want to know. Now, the issue is that using the Felix IModule naming, would it be correct to say that the spec implies that: - If we have a module X that is being updated, and there is another module Y that is wired to X, then X must remain available to future resolves. This future resolves includes new bundles. ? Yes. Ok Hope this helps. It helped a lot, huge thanks. Regards, Lucas regards, Karl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bundle update not following the spec?
Hi, The standard also reads quote 4.3.10 Updating Bundles [...] The update process supports migration from one version of a bundle to a newer version of the same bundle. The exports of an updated bundle must be immediately available to the Framework. If none of the old exports are used, then the old exports must be removed. Otherwise, all old exports must remain available for existing bundles and future resolves until the refreshPackages method is called or the Framework is restarted. /quote Now, this is somehow different from what http://cwiki.apache.org/FELIX/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-ApacheFelixOSGiFrequentlyAskedQuestions reads, this may not be too bad as you may say that the wiki is just slightly incomplete. Just as I said, not Not too bad. Why is it incomplete? The wiki reads (cut some cutpaste to make it clearer) 1. Your bundle does not export any packages. - The updated classes should become available immediately. 2. Your bundle exports some packages, but does not import those same packages. - The updated classes should become available immediately. - However other bundles using the exported packages from the updated bundle will not start using the new classes until PackageAdmin.refreshPackages() is called (this can be invoked in the Felix shell using the refresh command). 3. Your bundle exports some packages and also imports those same packages (see the importing and exporting FAQ below). - Neither the updated bundle nor any bundles importing packages from the updated bundle will see any updated classes until the packages are refreshed. 1. If no bundle is wired to the old module by the use of an import or dynamic import.* - The updated classes should become available immediately. - The old module will be removed and cannot be used to resolve a bundle. * Note: If your bundle does not export, then no bundle can create a wire to it. 2. There is a bundle wired to old module by the use of an import or dynamic import (this bundle may be the same bundle being updated). - Existing wires to this bundle will not start using the new classes until PackageAdmin.refreshPackages() is called. - The old module will remain and may be used to resolve a bundle until PackageAdmin.refreshPackages() is called. - New bundles and bundles that are updated may use the new or old module of the updated bundle. - All bundles using dynamic import may pick the new or old module of the updated bundle when creating a new wire. Is the above right? Even if the above is right, I think that using a simpler wording is better as a simplified interpretation of the FAQ may be after you update a bundle, execute a refresh and this is what 90% of the users want to know. Now, the issue is that using the Felix IModule naming, would it be correct to say that the spec implies that: - If we have a module X that is being updated, and there is another module Y that is wired to X, then X must remain available to future resolves. This future resolves includes new bundles. ? Yes. Ok Hope this helps. It helped a lot, huge thanks. Regards, Lucas regards, Karl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
