All point created as issues in Karaf. On Thu, Apr 2, 2009 at 2:13 PM, Guillaume Nodet <[email protected]> wrote:
> On Wed, Apr 1, 2009 at 14:48, Alin Dreghiciu <[email protected]> wrote: > > 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. > > Yeah, that may be a good idea. Though I don't see why it would fail > if there is no exporter. I guess this is a problem in the gshell-core > bundle, for which the dependency is not really optional. We should > fix this first, then see if it would be better to split this interface > from the main jar, which is imho a separate issue. > > > 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. > > Agreed. As I said above, I think the gshell console should work even > if no MainService is exported. > > > 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. > > Sounds good. > > > 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? > > Sure, that's a good idea. > > > 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. > > Right, that makes sense too. > > > 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. > > Not sure to really understand everything, but that does not look very good. > > > So, shall I spend time making Jira issues and patches? > > yes please ! > > > -- > > 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 > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- Alin Dreghiciu Software Developer - Looking for new projects! My profile: http://www.linkedin.com/in/alindreghiciu My blog: http://adreghiciu.blogspot.com http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development.
