You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Karl Pauls <ka...@gmail.com> on 2006/06/09 18:19:03 UTC
Autodetect JRE packages (was Re: [jira] Closed: (FELIX-78) Modify framework to export proper JRE packages for the execution environment)
In addition to the predefined package list solution we have now, I've
implemented an auto-detect solution. I think we could integrate the
two approaches by allowing a special property (e.g.,
${auto.detect.packages}) too. What it does is to scan the available
packages at system start-up.
Due to richard probably complaining about this being what we had in
the first place (namely, all packages are available) I've included the
possibility of a filter as well i.e., it is possible to filter the
packages by means of an LDAP filter based on two properties:
Package-Name and Package-Source. For Example:
${auto.detect.packages}
package.filter=(|(Package-Name=java.*)(Package-Name=javax.*)(Package-Name=org.omg.*))
yields the same result as our static defined package-lists.
Additionally, one would be able to add special stuff either by name or
by location:
package.filter=(|(Package-Name=java.*)(Packag-Name=quicktime.*)(Package-Source=classes))
Does this sound like a good idea?
regards,
Karl
On 6/9/06, Richard S. Hall (JIRA) <ji...@apache.org> wrote:
> [ http://issues.apache.org/jira/browse/FELIX-78?page=all ]
>
> Richard S. Hall closed FELIX-78:
> --------------------------------
>
> Resolution: Fixed
>
> Excellent. We should keep this command around for JDK 1.6...thanks Niclas. I have committed the new config file with update property definitions.
>
> > Modify framework to export proper JRE packages for the execution environment
> > ----------------------------------------------------------------------------
> >
> > Key: FELIX-78
> > URL: http://issues.apache.org/jira/browse/FELIX-78
> > Project: Felix
> > Type: Improvement
>
> > Components: Framework
> > Reporter: Richard S. Hall
> > Priority: Minor
> > Attachments: jre1.3.packages, jre1.3.packages, jre1.4.packages, jre1.4.packages, jre1.5.packages, jre1.5.packages
> >
> > The OSGi specification requires that class path classes are hidden from bundles. To expose classes on the class path, the system bundle can be made to "export" them by adding the packages to the org.osgi.framework.system.packages property in the config.properties file.
> > The should create proper value definitions for this property for JDKs 1.3, 1.4, and 1.5 and perhaps define some way in the config.properties file to specify system property guards for enabling/disabling various properties, so that we can add all three values to the config.properties file, but only enable the value corresponding to the appropriate execution platform at run time.
> > Of course, this is just one possible suggestion for a solution. Perhaps there is a better one.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
>
--
Karl Pauls
karlpauls@gmail.com
Re: Autodetect JRE packages (was Re: [jira] Closed: (FELIX-78) Modify framework to export proper JRE packages for the execution environment)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 11 June 2006 05:29, Marcel Offermans wrote:
> I would prefer to have this as a small project under tools too
+1
Niclas
Re: Autodetect JRE packages (was Re: [jira] Closed: (FELIX-78) Modify
framework to export proper JRE packages for the execution environment)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
We never really settled on tooling naming, but it is fine for now.
-> richard
Karl Pauls wrote:
>> Well, we can start with the tool first. Later we can create an
>> alternative Main that includes the auto-detect feature.
>
> I lost track about the current state of naming affairs ...
> Is org.apache.felix.tool.autodetect o.k. for now?
>
>> -> richard
>
> regards,
>
> Karl
>
Re: Autodetect JRE packages (was Re: [jira] Closed: (FELIX-78) Modify framework to export proper JRE packages for the execution environment)
Posted by Karl Pauls <ka...@gmail.com>.
> Well, we can start with the tool first. Later we can create an
> alternative Main that includes the auto-detect feature.
I lost track about the current state of naming affairs ...
Is org.apache.felix.tool.autodetect o.k. for now?
> -> richard
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Re: Autodetect JRE packages (was Re: [jira] Closed: (FELIX-78) Modify
framework to export proper JRE packages for the execution environment)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Karl Pauls wrote:
> Still think it would be a useful optional framework feature...
Well, we can start with the tool first. Later we can create an
alternative Main that includes the auto-detect feature.
Ultimately, if its impact on performance and resource consumption is
proved to be very small, then it is possible to just merge the two
Mains, but it will still only benefit some very small percentage of people.
-> richard
Re: Autodetect JRE packages (was Re: [jira] Closed: (FELIX-78) Modify framework to export proper JRE packages for the execution environment)
Posted by Karl Pauls <ka...@gmail.com>.
> I would prefer to have this as a small project under tools too,
No objections. I'll commit something in due course.
> The impact on (startup) performance might seem little (even on old
> hardware) but for certain embedded systems with less processing power
> it might still be too much.
That's why I did talk about making it an optional feature that _may_
be used but is not the default :-)
> I agree with Richard that the package list will be a static set for a
> specific OSGi framework installation. When installing the framework
> and choosing the JRE (and probably settting the execution
> environment) you determine the environment.
I disagree. This is a valid point of view but it is not the only one.
The point is that a JRE might change or "be extended" (using the
classpath, the extension dir, etc.). With a static list the list has
to be adapted manually - This probably is o.k. most of the time but
I'd like the possibility to just let the framework take care of that.
> I think the solution to this question is simple. If your bundle needs
> javax.comm to be available, then it must either import it or include
> a private copy. If you decide to import it, someone has to export it
> (either the system bundle, or you can choose to do that from a
> separate bundle).
Oh well, the problem with examples always is to find a good one :-).
The issue here is that it is not possible to bundle javax.comm due to
legal/licensing issues plus it needs to be on the bootclasspath. In
other words one can advise the user to install javax.comm in the
bootclasspath but can not bundle it up. That's the hole point.
Again, there are other examples (probably better once too). The
overall question is do we provide an auto detect feature additionally
to a static list or not.
> Basically you're installing JRE extensions here and you want to
> detect them and export the packages that have been installed as
> extensions. For this specific scenario your solution does help, if
> you restart the OSGi framework after each modification.
Exactly, my solution does help - a static list of packages does not
(in this scenario).
> Greetings, Marcel
I'm fine with committing my stuff to tools. It's down to 0.1-0.3
seconds if nothing changed while still at about 5 seconds on the first
run. If nothing else I'll let it output something that can be used as
the jre-packages property.
Still think it would be a useful optional framework feature...
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Re: Autodetect JRE packages (was Re: [jira] Closed: (FELIX-78) Modify framework to export proper JRE packages for the execution environment)
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello Karl,
I would prefer to have this as a small project under tools too,
instead of using it as a dynamic system package exporter at runtime.
The impact on (startup) performance might seem little (even on old
hardware) but for certain embedded systems with less processing power
it might still be too much. But that's not the main reason for me to
prefer having it as a tool.
I agree with Richard that the package list will be a static set for a
specific OSGi framework installation. When installing the framework
and choosing the JRE (and probably settting the execution
environment) you determine the environment.
On Jun 10, 2006, at 14:59 , Karl Pauls wrote:
>> However, I still think the predefined list solution is somewhat to
>> restrictive. Consider, for example, I want to have the javax.comm
>> packages. Due to some restrictions (legal and availability) they must
>> be on the system loader. My Bundle needs them hence, has a hard
>> dependency on the javax.comm package. What do I do in regard to
>> shipping to arbitrary platforms? If I include the javax.comm package
>> in the package property then my bundle gets started regardless of
>> whether the packages are actually there and if I don't it never will
>> be started...
I think the solution to this question is simple. If your bundle needs
javax.comm to be available, then it must either import it or include
a private copy. If you decide to import it, someone has to export it
(either the system bundle, or you can choose to do that from a
separate bundle).
>> There are some other similar scenarios I can see and, yes, one could
>> work around all of them without including an auto-detect feature in
>> the framework, however, all workarounds I can think of are somewhat
>> ugly (due to involving user actions).
Basically you're installing JRE extensions here and you want to
detect them and export the packages that have been installed as
extensions. For this specific scenario your solution does help, if
you restart the OSGi framework after each modification.
Greetings, Marcel
Re: Autodetect JRE packages (was Re: [jira] Closed: (FELIX-78) Modify framework to export proper JRE packages for the execution environment)
Posted by Karl Pauls <ka...@gmail.com>.
> > In general, it is cool to be able to auto-generate the available
> > packages. However, I don't see it being a good idea in practice.
>
> I know. The question was more in the direction of having the
> possibility (not the default and no advertisement :-).
>
> > The package list should generally be a rather static set, so I don't see
> > people wanting to re-generate this each time they start their framework
> > for a given deployment.
>
> Are you worried about the performance impact? Its about 4 seconds on
> my PowerBook 1G (~3.5 years old) including a rather complicated filter
> plus it would be very easy to add some caching...
>
> > A better way to use this capability would be to
> > use it to generate your static system packages property for your
> > config.properties file when you deploy the framework.
>
> Well, I can see that too. I could start a small project under tools
> that would print all the available packages restricted by a filter
> argument.
>
> > Just my $0.02...
> >
> > -> richard
>
> However, I still think the predefined list solution is somewhat to
> restrictive. Consider, for example, I want to have the javax.comm
> packages. Due to some restrictions (legal and availability) they must
> be on the system loader. My Bundle needs them hence, has a hard
> dependency on the javax.comm package. What do I do in regard to
> shipping to arbitrary platforms? If I include the javax.comm package
> in the package property then my bundle gets started regardless of
> whether the packages are actually there and if I don't it never will
> be started...
>
> There are some other similar scenarios I can see and, yes, one could
> work around all of them without including an auto-detect feature in
> the framework, however, all workarounds I can think of are somewhat
> ugly (due to involving user actions).
>
> regards,
>
> Karl
>
> --
> Karl Pauls
> karlpauls@gmail.com
Just to clarify, it takes 4 seconds when started inside eclipse :-).
Additionally, I've added some simple caching now and the result is ~5
seconds for the first time (i.e., nothing cached) and ~1 second if
nothing changed (i.e., only the cached values are used). I think that
is acceptable (given that all figures are from inside eclipse).
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Re: Autodetect JRE packages (was Re: [jira] Closed: (FELIX-78) Modify framework to export proper JRE packages for the execution environment)
Posted by Karl Pauls <ka...@gmail.com>.
> In general, it is cool to be able to auto-generate the available
> packages. However, I don't see it being a good idea in practice.
I know. The question was more in the direction of having the
possibility (not the default and no advertisement :-).
> The package list should generally be a rather static set, so I don't see
> people wanting to re-generate this each time they start their framework
> for a given deployment.
Are you worried about the performance impact? Its about 4 seconds on
my PowerBook 1G (~3.5 years old) including a rather complicated filter
plus it would be very easy to add some caching...
> A better way to use this capability would be to
> use it to generate your static system packages property for your
> config.properties file when you deploy the framework.
Well, I can see that too. I could start a small project under tools
that would print all the available packages restricted by a filter
argument.
> Just my $0.02...
>
> -> richard
However, I still think the predefined list solution is somewhat to
restrictive. Consider, for example, I want to have the javax.comm
packages. Due to some restrictions (legal and availability) they must
be on the system loader. My Bundle needs them hence, has a hard
dependency on the javax.comm package. What do I do in regard to
shipping to arbitrary platforms? If I include the javax.comm package
in the package property then my bundle gets started regardless of
whether the packages are actually there and if I don't it never will
be started...
There are some other similar scenarios I can see and, yes, one could
work around all of them without including an auto-detect feature in
the framework, however, all workarounds I can think of are somewhat
ugly (due to involving user actions).
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Re: Autodetect JRE packages (was Re: [jira] Closed: (FELIX-78) Modify
framework to export proper JRE packages for the execution environment)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
In general, it is cool to be able to auto-generate the available
packages. However, I don't see it being a good idea in practice.
The package list should generally be a rather static set, so I don't see
people wanting to re-generate this each time they start their framework
for a given deployment. A better way to use this capability would be to
use it to generate your static system packages property for your
config.properties file when you deploy the framework.
Just my $0.02...
-> richard
Karl Pauls wrote:
> In addition to the predefined package list solution we have now, I've
> implemented an auto-detect solution. I think we could integrate the
> two approaches by allowing a special property (e.g.,
> ${auto.detect.packages}) too. What it does is to scan the available
> packages at system start-up.
>
> Due to richard probably complaining about this being what we had in
> the first place (namely, all packages are available) I've included the
> possibility of a filter as well i.e., it is possible to filter the
> packages by means of an LDAP filter based on two properties:
> Package-Name and Package-Source. For Example:
>
> ${auto.detect.packages}
>
> package.filter=(|(Package-Name=java.*)(Package-Name=javax.*)(Package-Name=org.omg.*))
>
>
> yields the same result as our static defined package-lists.
> Additionally, one would be able to add special stuff either by name or
> by location:
>
> package.filter=(|(Package-Name=java.*)(Packag-Name=quicktime.*)(Package-Source=classes))
>
>
>
> Does this sound like a good idea?
>
> regards,
>
> Karl
>
> On 6/9/06, Richard S. Hall (JIRA) <ji...@apache.org> wrote:
>> [ http://issues.apache.org/jira/browse/FELIX-78?page=all ]
>>
>> Richard S. Hall closed FELIX-78:
>> --------------------------------
>>
>> Resolution: Fixed
>>
>> Excellent. We should keep this command around for JDK 1.6...thanks
>> Niclas. I have committed the new config file with update property
>> definitions.
>>
>> > Modify framework to export proper JRE packages for the execution
>> environment
>> >
>> ----------------------------------------------------------------------------
>>
>> >
>> > Key: FELIX-78
>> > URL: http://issues.apache.org/jira/browse/FELIX-78
>> > Project: Felix
>> > Type: Improvement
>>
>> > Components: Framework
>> > Reporter: Richard S. Hall
>> > Priority: Minor
>> > Attachments: jre1.3.packages, jre1.3.packages, jre1.4.packages,
>> jre1.4.packages, jre1.5.packages, jre1.5.packages
>> >
>> > The OSGi specification requires that class path classes are hidden
>> from bundles. To expose classes on the class path, the system bundle
>> can be made to "export" them by adding the packages to the
>> org.osgi.framework.system.packages property in the config.properties
>> file.
>> > The should create proper value definitions for this property for
>> JDKs 1.3, 1.4, and 1.5 and perhaps define some way in the
>> config.properties file to specify system property guards for
>> enabling/disabling various properties, so that we can add all three
>> values to the config.properties file, but only enable the value
>> corresponding to the appropriate execution platform at run time.
>> > Of course, this is just one possible suggestion for a solution.
>> Perhaps there is a better one.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the administrators:
>> http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> For more information on JIRA, see:
>> http://www.atlassian.com/software/jira
>>
>>
>
>