You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2005/10/10 12:35:53 UTC
Oscar --> Felix
Hi,
I am moving one app from Oscar 1.0.5 to Felix HEAD.
I will be using this thread to report any behaviour that differs, and needs to
be either 'fixed' or documented.
In Oscar, I could put
-Doscar.cache.dir=<some file location>
on the command-line. It seems that in Felix, it is no longer possible to do
the equivalent. Instead these properties must go into the "configuration
properties" file.
This seems to be the case for the felix.auto.install and felix.auto.start as
well.
Cheers
Niclas
Re: Oscar --> Felix
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 11 October 2005 00:01, Richard S. Hall wrote:
> Niclas Hedhman wrote:
> >The shellplugin from Oscar fails to locate bundlerepository, and the
> > shellgui subsequently becomes empty.
>
> Which versions of shellplugin are you using? I really haven't focused
> too much on it yet.
AFAICT, the shellgui and shellplugin has not been ported across to Felix, and
I really like the GUI interface. So, I took those from Oscar 1.0.5. But the
shellplugin protest that it can't find "org.ungoverned..." something, since
that is now in "org.apache.felix....". Therefor I carried across the shell
and shelltui as well. It seems to work with all of them in there.
> >But by loading up all the the Oscar bundles (shell, shelltui, shellgui,
> >bundlerepository and tablelayout) in parallel with the Felix current
> > bundles (shell, shelltui and bundlerepository) things actually seems to
> > work somewhat.
>
> For Oscar 2.0 beta, I did try to modify shellplugin, etc. to work with
> it, but I haven't really did any testing with them for Felix. If you are
> using the bundles for Oscar 1.0.x, then you will likely run into some
> difficulties.
Will look out for the "difficulties"
> >Not sure who owns the console though, and command "version" returns
> > "null". I would guess the first one loaded (i.e. Felix one).
>
> If you are running the console for Oscar 1.0.x with Felix, then it won't
> find the version because the property name has changed. You should be
> using the shell, shelltui, and bundlerepository from Felix HEAD.
Interesting, since the Felix shelltui is loaded prior to the Oscar shelltui,
and I would expect the Felix one to grab the System.in.
> >Question; Should I keep using only the Oscar bundles, or use the mix of
> > Oscar and Felix ones??
>
> Well, for the shell and related bundles, you should probably use the
> Felix ones for now. For all other bundles, you can try to use them with
> Felix, but you could run into some difficulties because Felix is more
> strict with how classes on the class path are exposed...thus, you might
> see some class not found exceptions or the like.
Can we port these across ASAP, so I can drop the Oscar ones??
> If you want to expose classes on the class path, modify the property
> org.osgi.framework.system.packages in lib/config.properties to include
> the class path packages that you want to be exported by the system bundle.
10-4.
Cheers
Niclas
Re: Oscar --> Felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
>The shellplugin from Oscar fails to locate bundlerepository, and the shellgui
>subsequently becomes empty.
>
>
Which versions of shellplugin are you using? I really haven't focused
too much on it yet.
>But by loading up all the the Oscar bundles (shell, shelltui, shellgui,
>bundlerepository and tablelayout) in parallel with the Felix current bundles
>(shell, shelltui and bundlerepository) things actually seems to work
>somewhat.
>
>
For Oscar 2.0 beta, I did try to modify shellplugin, etc. to work with
it, but I haven't really did any testing with them for Felix. If you are
using the bundles for Oscar 1.0.x, then you will likely run into some
difficulties.
>Not sure who owns the console though, and command "version" returns "null". I
>would guess the first one loaded (i.e. Felix one).
>
>
If you are running the console for Oscar 1.0.x with Felix, then it won't
find the version because the property name has changed. You should be
using the shell, shelltui, and bundlerepository from Felix HEAD.
>Quite happy that it is possible to use the Oscar material, while getting Felix
>up to the same level.
>
>Question; Should I keep using only the Oscar bundles, or use the mix of Oscar
>and Felix ones??
>
>
Well, for the shell and related bundles, you should probably use the
Felix ones for now. For all other bundles, you can try to use them with
Felix, but you could run into some difficulties because Felix is more
strict with how classes on the class path are exposed...thus, you might
see some class not found exceptions or the like.
If you want to expose classes on the class path, modify the property
org.osgi.framework.system.packages in lib/config.properties to include
the class path packages that you want to be exported by the system bundle.
-> richard
Re: Oscar --> Felix
Posted by Niclas Hedhman <ni...@hedhman.org>.
The shellplugin from Oscar fails to locate bundlerepository, and the shellgui
subsequently becomes empty.
But by loading up all the the Oscar bundles (shell, shelltui, shellgui,
bundlerepository and tablelayout) in parallel with the Felix current bundles
(shell, shelltui and bundlerepository) things actually seems to work
somewhat.
Not sure who owns the console though, and command "version" returns "null". I
would guess the first one loaded (i.e. Felix one).
Quite happy that it is possible to use the Oscar material, while getting Felix
up to the same level.
Question; Should I keep using only the Oscar bundles, or use the mix of Oscar
and Felix ones??
Cheers
Niclas
Re: Oscar --> Felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Currently, security support is not implemented. This is one of the JIRA
issues that I will soon post.
-> richard
Niclas Hedhman wrote:
>A lot of the privileged execution has been commented out. This means that if a
>SecurityManager is installed, Felix will not operate. Most notably, no
>bundles will be started.
>
>I guess Richard have some plan about this, but I would like to see a better
>strategy. Example;
>
>Instead of;
>
>if (System.getSecurityManager() != null)
>{
>// m_startStopPrivileged.setAction(StartStopPrivileged.START_ACTION);
>// m_startStopPrivileged.setBundle(bundle);
>// AccessController.doPrivileged(m_startStopPrivileged);
>}
>else
>{
> info.getActivator().start(info.getContext());
>}
>
>I would like to modified it to
>
>//if (System.getSecurityManager() != null)
>//{
>// m_startStopPrivileged.setAction(StartStopPrivileged.START_ACTION);
>// m_startStopPrivileged.setBundle(bundle);
>// AccessController.doPrivileged(m_startStopPrivileged);
>//}
>//else
>//{
> info.getActivator().start(info.getContext());
>//}
>
>And a TODO tag, with a comment of what is needed. At least the code will run
>with an SM installed.
>
>
>
>Cheers
>Niclas
>
>
>
>
>
Re: Oscar --> Felix
Posted by Niclas Hedhman <ni...@hedhman.org>.
A lot of the privileged execution has been commented out. This means that if a
SecurityManager is installed, Felix will not operate. Most notably, no
bundles will be started.
I guess Richard have some plan about this, but I would like to see a better
strategy. Example;
Instead of;
if (System.getSecurityManager() != null)
{
// m_startStopPrivileged.setAction(StartStopPrivileged.START_ACTION);
// m_startStopPrivileged.setBundle(bundle);
// AccessController.doPrivileged(m_startStopPrivileged);
}
else
{
info.getActivator().start(info.getContext());
}
I would like to modified it to
//if (System.getSecurityManager() != null)
//{
// m_startStopPrivileged.setAction(StartStopPrivileged.START_ACTION);
// m_startStopPrivileged.setBundle(bundle);
// AccessController.doPrivileged(m_startStopPrivileged);
//}
//else
//{
info.getActivator().start(info.getContext());
//}
And a TODO tag, with a comment of what is needed. At least the code will run
with an SM installed.
Cheers
Niclas
Re: Oscar --> Felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Yes, this behavior changed in Felix. The idea was that the framework
should not be dependent on "globals", because this would be problematic
for situations when there are multiple instances of the framework.
Of course, it is still possible to create a "launcher" that looks for
these system properties and then feeds them into Felix' constructor.
-> richard
Niclas Hedhman wrote:
>Hi,
>
>I am moving one app from Oscar 1.0.5 to Felix HEAD.
>I will be using this thread to report any behaviour that differs, and needs to
>be either 'fixed' or documented.
>
>
>In Oscar, I could put
>
> -Doscar.cache.dir=<some file location>
>
>on the command-line. It seems that in Felix, it is no longer possible to do
>the equivalent. Instead these properties must go into the "configuration
>properties" file.
>
>This seems to be the case for the felix.auto.install and felix.auto.start as
>well.
>
>
>Cheers
>Niclas
>
>
>
>
>