Hi guys, I like the SMXK GShell and yesterday I created a Pax Runner profile for it so you can just do pax-run --profiles=smx.kernel.gshell --noconsole to easy use gshell in felix or any other framework. --no console in Pax `runner means that the framework provided framework is not installed/shown. I have it running now but doing this I stumble upon the things bellow. I also realize that the SMXK stuff is not in its main purpose to be used as pieces and not as a whole product but I think what I'm proposing it will not affect it main purpose, just make it usable as parts.
1. MainService location: To have LocalConsole working from org.apache.servicemix.kernel.gshell.core it needs org.apache.servicemix.kernel.main.spi which even if is marked optional (I believe that is valid only when the remote console is used) it will fail if there is no exporter for the package. Now the exporter is org.apache.servicemix.kernel.main but it does not sound right to me to just install that jar, which includes felix and other osgi packages. My suggestion: create another bundle just for spi package or handle the case that the MainService class is not there especially in relation with next item. 2. MainService optional When using the LocalConsole there is a dependency of an MainService implementation. The main service is normally provided by the main jar so when I do not use the main SMX jar the service is not there, which makes gshell core not start waiting for the dependency to be fulfilled. This I can easily solve by having a bundle that implements a default service where there are no arguments and the exit code is just stored. But I would say that such handling can be easy done within the gshell itself by thinking of ManService as an optional service. If is not there just use a fake local implementation that has not arguments and stores the exit code. If you would go for a solution (see above point) where the main service is really optional a different approach is needed but can be easily be archived. 3. Make Thread in LocalConsole not a daemon thread. When using the LocalConsole in Equinox without console, equinox will exit if their own console is not there (and is not there because we use GShell) unless there is a non daemon thread. So, just mark the created thread as non daemon. 4. Default properties. There are some properties that are set by the scrips such as in my case: -Dservicemix.base=. -Dservicemix.name=root -Dservicemix.startLocalConsole=true -Dservicemix.startRemoteShell=false If those properties are not there Spring will complain about and do not start the components using them. Can't there be some defaults as for example above? 5. org.apache.servicemix.kernel.gshell.features dependency on org.apache.servicemix.kernel.filemonitor as optional Features depend on filemonitor in order to handle automatically features file deployed in the directory watched by filemonitor. But this is an optional thing as features are very much useful without the filemonitor. Actually my suggestion is to move FeatureDeploymentListener in its own bundle and let him use the FeaturesService. This way the features will not depend on filemonitor. 6. Bug in Feature.getDependencies? Another thing that I implemented in Pax Runner is a scanner for features. Meaning that you can do pax-run scan-feature:mvn:org.apache.servicemix.nmr/apache-servicemix-nmr/1.0.0/xml/features!/jbi-1.0.0. This also works now but I noticed the following: Lets say that you have 3 features: A, B, C where B depends on A and C depends on A. If I do Repository.getFeatures i will get an array containing three Features instances AI1, BI1, CI1. Because B depends on A I can get the dependencies of AI1, which I would expect to be BI1 but actually is another Feature instance BI2. Lets say that wouldn't be such a problem but main problem is that BI2 does not have a dependency on CI1 nor it has any bundles. So, shall I spend time making Jira issues and patches? -- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. Looking for a job. Sent from Cluj-Napoca, CJ, Romania
