On 10/27/15 16:10 , Balázs Zsoldos wrote:
I guess your needs came from an environment I am not familiar with. I have
never had to use Permissions within OSGi, so I must discontinue the
argument here (until I get familiar once with OSGi security ;-) ).
Probably the different opinions come from the name "system.packages". If
there were "framework.packages" and "environment.packages" that would give
a better separation. The chance of having such discussion has gone long ago.
Considering that the system bundle is called a "system" bundle, then it
would seem that the relationship to "system" packages would be clear... :-)
Anyway, I would like to ask kindly you if it is possible to implement the
idea that you (Richard) proposed in one of your previous emails:
org.osgi.framework.system.packages= ${dollar}{framework-exports} \
${dollar}{jre-${dollar}{java.specification.version}}
That could save lots of work in the future for developers who want to
specify explicitly those JDK packages they need. I hope that in one day all
packages can come from bundles (all, even swing or other built-in
solutions), and we need to export only the framework packages.
You can certainly create an issue for this...
-> richard
On Tue, Oct 27, 2015 at 6:33 PM, Richard S. Hall <he...@ungoverned.org>
wrote:
On 10/27/15 13:27 , Balázs Zsoldos wrote:
Also, we used to package some framework services separately (e.g.,
PackageAdmin, etc.) and some framework still might, so this assumption
also
is not correct.
I am wondering why PackageAdmin had to be re-implemented. If it was
possible to re-implement it based on other features of OSGi Core, does
that
mean that OSGi Core contained something that it should not have? If some
services can be implemented based on others, they are more like libraries
than part of the core.
I didn't say it was re-implemented, I said it was packaged separately. We
still do, for example, package the permission-related services separately.
It did, however, use some special hooks to do what it needed to do.
-> richard
E.g.: BundleTracker and ServiceTracker is part of a very helpful library.
It can be implemented based on OSGi Core. I am probably alone with the
opinion that is should not have been moved into OSGi Core. Also, it is
another discussion (I am sure this was discussed internally before
releasing OSGi Core 5).
On Tue, Oct 27, 2015 at 6:08 PM, Richard S. Hall <he...@ungoverned.org>
wrote:
On 10/27/15 11:27 , Balázs Zsoldos wrote:
@David:
I know about the *org.osgi.framework.system.**packages.extra* property,
but
that is about another use-case.
*org.osgi.framework.system.**packages.extra *can be used to extend the
list
of system packages.
*org.osgi.framework.system.**packages* can be used to reduce the list of
the system packages.
I want to reduce the list of system packages as some packages are coming
from bundles. More specifically, I want to list only those packages
that I
actually need from the JDK. Reason: Many packages are incomplete or
buggy
in the JDK: javax.transaction.*, javax.xml.*...
@Andy:
The text at
https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES
says:* Framework launching property identifying packages which the
system
bundle must export.*
"Must" does not mean that only those packages should be exported by the
system bundle.
@Everyone:
Questions:
- What is the exact meaning of system packages from the
perspective of
this setting? In my opinion, the list of packages that are coming
outside
the OSGi container. org.osgi.* packages do not come outside from
the
OSGi
container.
- Could the org.osgi.* packages come from custom bundles? I think,
no.
- Can you write an application that does not need any of the
org.osgi.*
package? I think you cannot. At least one bundle has to implement
an
Activator to have any kind of functionality in the system.
Otherwise
the
bundles will be resolved, but they will do nothing (not even a
static
block
will be called).
- Can you imagine any use-case where exporting org.osgi.* packages
by
the system bundle could cause any issue? I cannot.
Also, we used to package some framework services separately (e.g.,
PackageAdmin, etc.) and some framework still might, so this assumption
also
is not correct.
- Is it an extra work that org.osgi.* packages have to be appended
if
system.packages are overridden? Yes, always.
Sure, this is correct, but not really relevant to the meaning of system
packages.
-> richard
If we answer these questions, we will come to the conclusion (at least I
:)
) that org.osgi.* packages should always be exported by the system
bundle.
They are not in the scope of the meaning of system.packages setting.
Kind regards,
*Balázs **Zsoldos*
On Tue, Oct 27, 2015 at 3:21 PM, David Bosschaert <
david.bosscha...@gmail.com> wrote:
Yes, that's precisely what the
org.osgi.framework.system.packages.extra was designed for. That way
you don't need to remember what the framework puts on
org.osgi.framework.system.packages in order to augment it.
Best regards,
David
On 27 October 2015 at 14:18, Andy Lee <thelees.a...@gmail.com> wrote:
If you are trying to extend the set of packages exported by the system
bundle, you should use org.osgi.framework.system.packages.extra. By
specifying org.osgi.framework.system.packages you are overriding the
default value used by the framework, and hence must include the
packaged
that are expected to be supplied by the framework.
See
https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES
--Andy
On Tue, Oct 27, 2015 at 10:00 AM, Balázs Zsoldos <
balazs.zsol...@everit.biz>
wrote:
Hi,
I asked this 1-2 years ago, but I think it is worthy to ask it
again.
Are you sure that the set of system packages should include the OSGi
core
packages?
In my understanding:
- system packages are the ones coming from outside of the OSGi
container
- osgi core packages are offered by the framework bundle, but
they
are
not system packages
In practice:
- If I specify org.osgi.system.packages property for equinox, I
do
not
have to define the packages implemented by the framework
- If I specify the same property for felix, I must copy-paste
the
packages of osgi.core always
Do you think there is a use-case when osgi.core packages offered by
the
framework should be excluded from the exported packages of the system
bundle? I think Equinox has the right behavior here.
Do you see any chance to change this behavior in the future?
Kind regards,
*Balázs **Zsoldos*
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
