Using SMXK GShell from Pax Runner

[Alin Dreghiciu <ad...@gmail.com>]

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

Re: Using SMXK GShell from Pax Runner

[Alin Dreghiciu <ad...@gmail.com>]

All point created as issues in Karaf.

On Thu, Apr 2, 2009 at 2:13 PM, Guillaume Nodet <gn...@gmail.com> wrote:

> On Wed, Apr 1, 2009 at 14:48, Alin Dreghiciu <ad...@gmail.com> 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.

Re: Using SMXK GShell from Pax Runner

[Guillaume Nodet <gn...@gmail.com>]

On Wed, Apr 1, 2009 at 14:48, Alin Dreghiciu <ad...@gmail.com> 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