On Thu, Apr 2, 2009 at 12:40, Alin Dreghiciu <[email protected]> wrote: > > Yesterday I sent the following message to the dev list of smx but Charles > told me that the list is for committers. So, here is again, now on the right > list:
It's not a list for committers only, it's a public list for discussing ServiceMix development (which means users are welcome to discuss any issue there), so I'll reply there. > > 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 > -- > View this message in context: > http://www.nabble.com/SMX-Kernel-GShell-improvements-tp22845110p22845110.html > Sent from the ServiceMix - User mailing list archive at Nabble.com. > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
