i am currently evaluating osgi (using the felix 4.3 implementation) to manage versionning of services.
i have been creating the following bundles:
bundle-api (version 1.0.0) that defines interface x.y.z.SomeService:
it exports x.y.z in version 1.0.0
bundle-impl (version 1.0.0) that implements SomeService (v 1.0.0), imports package x.y.z in specification-version 1.0.0 and that registers the service
bundle-api (version 2.0.0) that defines interface x.y.z.SomeService:
it exports x.y.z in version 2.0.0
bundle-impl (version 2.0.0) that implements SomeService (v 2.0.0), imports package x.y.z in specification-version 2.0.0 and that registers the service
now, i have a client, bundle-client (version 1.0.0) that imports bundle-api's x.y.z in version specification-1.0.0.
how do i get the services for x.y.z.SomeService in version 1.0.0 ?
currently, when installing / activating:
bundle-api 1.0.0
bundle-impl 1.0.0
bundle-api 2.0.0
bundle-impl 2.0.0
bundle-client 1.0.0
when start bundle-client, it queries for the available x.y.y.SomeService.
i get as answer for the available services:
bundle-impl 1.0.0 and bundle-impl 2.0.0
i would like to get only the service implementations that do match version 1.0.0.
how should i proceed ?
ps: currently, i'm setting null as filter value.
What code or mechanism are you using to query the services? OSGi provides service compatibility filtering automatically, which means that if your client imports version 1.0 of an API then it will only see services that implement version 1.0, and if your client imports version 2.0 of the API then it will only see services that implement version 2.0.... etc.
However there is a method call getAllServiceReferences() that explicitly turns off this compatibility check, and can be used to get all services of all versions. In 99% of cases this is NOT what you want to do. If you have used getAllServiceReferences() then try changing to getServiceReferences().
If you are looking up services in some other way, then I need more detail to help you further.
What you can do is publish the service with a property like version=1.0.0 and version=2.0.0. Then you can filter the service with (version=1.0.0).
I did not know that the services should be filtered by there package versions like Neil mentioned. As Neil really is an expert in this field I trust that he is right. So maybe there is a bug in the felix implementation?
A service is versioned by its interface's Java package. If you version that package correctly according to the OSGi semantic versioning model and do a corresponding package import then the OSGi framework will automatically do the selection for you. All OSGi services are versioned this way.
Maintaining this by hand is like compiling your java code to byte codes by hand, there are tools for that. bnd(tools) has extensive support to minimize handling and verifying these versions.
The whole idea of OSGi is that you are only exposed to compatible packages.
Related
I'm trying to upgrade from Neo4J 2.0.4 to 3.3.3 and I followed all the procedures as outlined on the single-instance upgrade page:
http://neo4j.com/docs/operations-manual/3.3/upgrade/deployment-upgrading/
I imported all the configs using the 2.x-config-migrator.jar utility and then ran neo4j-admin import to import the database from 2.0.4 into the 3.3.3, which seems to have worked.
However, when I try to start neo4j with the new database (running neo4j console to see errors as the normal neo4j start didn't work) I see the following error message after this:
2018-02-18 22:59:53.328+0000 INFO Starting upgrade of database
2018-02-18 22:59:53.335+0000 ERROR Failed to start Neo4j: Starting Neo4j failed: Component 'org.neo4j.server.database.LifecycleManagingDatabase#4ae9cfc1' was successfully initialized, but failed to start. Please see the attached cause exception "Not possible to upgrade a store with version 'v0.A.1' to current store versionv0.A.8(Neo4j 3.3.3).
I tried researching for this problem, but there's absolutely no info. The upgrade path 2.0.x(latest) to 3.3.2 is supported, so I guess it's the same for 3.3.3 as it's only a minor upgrade.
When I remove the imported database graph.db from the data folder and just try to run neo4j console on a freshly installed database I also get this error:
2018-02-18 23:09:31.440+0000 ERROR The ResourceConfig instance does not contain any root resource classes.
2018-02-18 23:09:31.440+0000 WARN unavailable The ResourceConfig instance does not contain any root resource classes.
However, when I install a clean database through Neo4J Desktop it runs fine.
I'm using Mac OS X 10.12.6 and Java 1.8.
How could I try to resolve this problem?
In the end, I have to answer this question myself as I spent several hours sorting this out.
First of all, Neo4J claims they support the upgrade path from the latest 2.x release to 3.x but this is not true. I had the version 2.0.4 (which is the latest 2.0 release and there were numerous problems migrating the settings and the old database into the new structure. It would simply not start.
I had to first upgrade to the latest stable 2.x version of Neo4J, which is 2.3.8. I ran into some problems with settings (I used authentification in 2.0.4 but I had to use the newly built in authentication module that 2.3.x provides, so I had to change some settings and remove the auth plugin). You also need to upgrade the database storage from 2.0.x to 2.3.x (by uncommenting the setting in conf).
Once you install and check that 2.3.8 is running and that your old database works, you need to then download the latest 3.x release.
However, the settings migration tool doesn't work properly. It creates numerous settings which are not supported by the new version, so you have to move them manually or not move them at all. Besides, the migration tool doesn't run under Java 1.7 so you might have to install Java 1.8 for the migration tool to even launch... So don't use it.
After that's done, provided you already upgraded your DB to the latest 2.x release, you can run the neo4j-admin import tool to import that DB into the new 3.x version and to convert it.
The whole process is described in detail here: https://github.com/noduslabs/infranodus/wiki/Upgrading-Your-Neo4J-Database-from-2.x-to-3.x
I am trying to pick up Grails using Groovy Grails tool suite. I tried to set up the tools to play around with Grails, unfortunately this issue which will need some advise. Please help me to resolve this problem.
These are the tools I had installed, using window 7:
1. Java JDK (jdk1.8.0_101)
2. Grails 2.3.4
3. Groovy Grails Tool Suite 3.5.1
Both Java and Grails are running fine. #cmd:
C:\Users\00Who00>java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
C:\Users\00Who00>grails -version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=32m; support
was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; sup
port was removed in 8.0
Grails version: 2.3.4
Grails 2.3 doesn't work with Java 8 because of the version of Groovy it uses; you need to use a newer version that uses a version of Groovy that's compatible. Either user Grails 2.4+ (or embrace 2016 and use an even more recent version) or switch to Java 7.
If you're getting started with Grails and attempting to use GGTS and Grails 2.3, I suspect you might be reading Grails in Action 2nd Ed. A fantastic book! Regardless, a couple of things to note:
Groovy-Grails Tool Suite has been discontinued for over a year, so is quite likely to have more issues
Grails 3.x is the latest and much improved (Gradle and Spock are defaults, among many other things)
For an IDE, I suggest switching to IntelliJ IDEA. If you are using Grails 3, both Ultimate and Community editions work fine since Grails 3 uses Gradle as a build tool. I'd definitely recommend the Grails 3/IntelliJ combo for getting up to speed, even if you need to switch back to 2.3 for work purposes. Nearly all the knowledge will transfer.
Available Grails 3 resources
There are no books yet on Grails 3 specifically. Here are some of the best resources I've found.
Grails 3 talks at SpringOne: infoq.com/conferences/springone2gx2015
Grails 3 User Guide: docs.grails.org/latest/guide/single.html
MrHaki's "Grails Goodness" series (which he offers compiled as a book also): mrhaki.blogspot.com/search/label/Grails%3AGoodness.
Beyond those, the Grails in Action 2nd Ed book is still very relevant and one of the best ways to get a comprehensive understanding of Grails.
Ok. So I have an old PowerMac G5 and I decided to use it as a staging server.
I went along trying to do all the normal installing rails things, when I experienced this error.
Could not find a JavaScript runtime. See https://github.com/sstephenson/ExecJS (GitHub) for a list of available runtimes (ExecJS::RuntimeUnavailable).
ExecJS and could not find a JavaScript runtime
As far as I can tell, this is because there is no javascript runtime for ExecJS to call. People suggested installing Node-JS to fix the problem. This makes sense.
Turns out, Node, which requires the V8 javascript engine, which required ARM or i386, doesn't run on PPC.
So am I screwed, or is there another Javascript runtime I can use for rails. And how would I set that up? Thanks.
Here is the PPC port of V8 actively developed by IBM folks:
https://github.com/andrewlow/v8ppc
I have a local server setup with SVN 1.6. If the client machine has SVN 1.7, will that be a problem?
p.s. This is with reference to Xcode, and iOS application development.
All 1.x clients are compatible with all 1.x servers via the RA layer (HTTP(S), SVN & SVN+SSH protocols). You can even go so far as to use a 1.0 client with a 1.8 server (or vice versa) - at the expense of newer features (the lowest common denominator is used).
Nope. Newer version most of the time compatible to old version. Just like Office 2010 can open Office 2003 files.
You can go for it.
I want to upgrade my web application to the latest JSF Mojarra (2.1.9 as of today is the latest) from Mojarra 2.0.5;
How do i do it ?...what are the steps involved ?..
At the moment my web app lib folder has got the old mojarra jars 'jsf-api.jar' and 'jsf-impl.jar'.
It would be a great help if any one can instruct each step . I am on a Websphere Application server 7.0.0.17
Just replace the two jsf-api.jar and jsf-impl.jar files from Mojarra 2.0.5 by the single javax-faces.jar file from Mojarra 2.1.9.
If Websphere 7 is already configured to use classloader mode "parent last", then you basically don't need to change anything else. But if it isn't (which would basically mean that the webapp-supplied Mojarra 2.0.5 was actually never been used and that Websphere's own JSF libraries is been used instead), then you still need to change the classloader mode to "parent last".