You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Jan S. Rellermeyer (JIRA)" <ji...@apache.org> on 2006/08/15 13:22:15 UTC
[jira] Created: (FELIXM2-8) Exported Package not found in bundle or
JARs on bundle class path (Feature or Bug ?)
Exported Package not found in bundle or JARs on bundle class path (Feature or Bug ?)
------------------------------------------------------------------------------------
Key: FELIXM2-8
URL: http://issues.apache.org/jira/browse/FELIXM2-8
Project: Felix M2 Plugin
Issue Type: Bug
Reporter: Jan S. Rellermeyer
Assigned To: Timothy Bennett
Priority: Minor
I have updated to the most recent version of the plugin and it seems that it now performs some checking if exported packages are in the classpath of the bundle that has declared it as export. Correct me, if I am wrong but I know from R3 that is is allowed to (re-) export packages that are imported (very common pattern in Knopflerfish bundles) and I think this is also possible in R4. So maybe the plugin should additionally check (and allow) packages that have been imported.
Jan.
--
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
Re: [jira] Commented: (FELIXM2-8) Exported Package not found in bundle or
JARs on bundle class path (Feature or Bug ?)
Posted by BJ Hargrave <ha...@us.ibm.com>.
Richard is correct :-)
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
"Richard S. Hall" <he...@ungoverned.org>
08/15/2006 11:57 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: [jira] Commented: (FELIXM2-8) Exported Package not found in bundle or
JARs on bundle class path (Feature or Bug ?)
Hey Jan,
>> As far as I understand the R3 spec, no re-exporting of
>> package is allowed at all. Page 47 of the R3 spec says, "The
>> Framework must guarantee that classes and resources in the
>> exported package's name-space are loaded from the exporting
>> bundle."
>>
>
> Well, this is not a contradiction to reexporting in my understanding, as
> long as the bundle classloader takes care about delegating reexported
> packages to the original exporter. So they are still loaded from the
> exported bundle but the delegation path goes through the reexporting
bundle.
> I'm not sure, but maybe this would be okay.
>
While I won't argue with your interpretation, since I think it is not an
unreasonable interpretation of the spec, I will say that I am fairly
certain that the R3 spec does not entertain the notion of re-exporting.
The R4 spec specifically does mention re-exporting, but this is only
allowed when using require-bundle.
Your message caused me to have a discussion with Peter Kriens about this
topic and he and I are in agreement on this...for whatever that buys
you. :-)
>> So, I think if KF allows this, then it is incorrect.
>>
>
> I have had a look at their bundles. In more recent versions, they export
a
> higher specification-version number than importing. I recall, there is
> something about it written in the specs. I should look it up ...
>
Exporting a higher version than what you import is not a way of doing
re-exporting...in that case the bundle does contain the exported
package, but the framework may not actually choose to use that export,
it may choose to wire the bundle to a different bundle for that package.
In R3 every export declaration has an implicit import
declaration...having an explicit import declaration [for an export] does
not really make its interpretation any different, it just allows the
bundle to specify a different version than what is exported. If a bundle
had an explicit import for the same version of a package that it
exported, then this would be identical to having no explicit import at
all for that package (i.e., the same as only exporting it).
The whole point of making exports imply imports in R3 was to allow
substitutability of packages so that bundles could interoperate. In R4,
exports do not implicitly imply an import any more, so if you want
interoperation you must include the import explicitly, which is
generally a good idea to do for any service interfaces that a bundle
exports.
The R4 spec clearly states that if a bundle both imports and exports the
same package, then the framework obeys one and discards the other (see
section 3.7).
> No, it's fine for the moment. Since the maven plugin is designed for R4,
I
> consider it to be a feature and not a bug :-)
Good. :-)
However, I do think it is correct for R3 too.
-> richard
Re: [jira] Commented: (FELIXM2-8) Exported Package not found in bundle
or JARs on bundle class path (Feature or Bug ?)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Hey Jan,
>> As far as I understand the R3 spec, no re-exporting of
>> package is allowed at all. Page 47 of the R3 spec says, "The
>> Framework must guarantee that classes and resources in the
>> exported package's name-space are loaded from the exporting
>> bundle."
>>
>
> Well, this is not a contradiction to reexporting in my understanding, as
> long as the bundle classloader takes care about delegating reexported
> packages to the original exporter. So they are still loaded from the
> exported bundle but the delegation path goes through the reexporting bundle.
> I'm not sure, but maybe this would be okay.
>
While I won't argue with your interpretation, since I think it is not an
unreasonable interpretation of the spec, I will say that I am fairly
certain that the R3 spec does not entertain the notion of re-exporting.
The R4 spec specifically does mention re-exporting, but this is only
allowed when using require-bundle.
Your message caused me to have a discussion with Peter Kriens about this
topic and he and I are in agreement on this...for whatever that buys
you. :-)
>> So, I think if KF allows this, then it is incorrect.
>>
>
> I have had a look at their bundles. In more recent versions, they export a
> higher specification-version number than importing. I recall, there is
> something about it written in the specs. I should look it up ...
>
Exporting a higher version than what you import is not a way of doing
re-exporting...in that case the bundle does contain the exported
package, but the framework may not actually choose to use that export,
it may choose to wire the bundle to a different bundle for that package.
In R3 every export declaration has an implicit import
declaration...having an explicit import declaration [for an export] does
not really make its interpretation any different, it just allows the
bundle to specify a different version than what is exported. If a bundle
had an explicit import for the same version of a package that it
exported, then this would be identical to having no explicit import at
all for that package (i.e., the same as only exporting it).
The whole point of making exports imply imports in R3 was to allow
substitutability of packages so that bundles could interoperate. In R4,
exports do not implicitly imply an import any more, so if you want
interoperation you must include the import explicitly, which is
generally a good idea to do for any service interfaces that a bundle
exports.
The R4 spec clearly states that if a bundle both imports and exports the
same package, then the framework obeys one and discards the other (see
section 3.7).
> No, it's fine for the moment. Since the maven plugin is designed for R4, I
> consider it to be a feature and not a bug :-)
Good. :-)
However, I do think it is correct for R3 too.
-> richard
RE: [jira] Commented: (FELIXM2-8) Exported Package not found in bundle or JARs on bundle class path (Feature or Bug ?)
Posted by "Jan S. Rellermeyer" <re...@inf.ethz.ch>.
Hi Rick,
> As far as I understand the R3 spec, no re-exporting of
> package is allowed at all. Page 47 of the R3 spec says, "The
> Framework must guarantee that classes and resources in the
> exported package's name-space are loaded from the exporting
> bundle."
Well, this is not a contradiction to reexporting in my understanding, as
long as the bundle classloader takes care about delegating reexported
packages to the original exporter. So they are still loaded from the
exported bundle but the delegation path goes through the reexporting bundle.
I'm not sure, but maybe this would be okay.
> So, I think if KF allows this, then it is incorrect.
I have had a look at their bundles. In more recent versions, they export a
higher specification-version number than importing. I recall, there is
something about it written in the specs. I should look it up ...
> As for R4, the spec only allows re-exporting of packages
> using require-bundle, not simply with import and export
> package. Thus, I think the maven plugin is right to enforce
> this...of course, it will eventually need to be updated to
> support require-bundle when it is implemented, but that is
> another issue. :-)
No, it's fine for the moment. Since the maven plugin is designed for R4, I
consider it to be a feature and not a bug :-)
Greets,
Jan.
-----------------------------------------------------------
ETH Zurich, MSc Jan S. Rellermeyer,
Information and Communication Systems Research Group (IKS),
Department of Computer Science, IFW B 47.1,
Haldeneggsteig 4, CH8092 Zürich
Tel +41 44 632 30 38, http://www.iks.inf.ethz.ch
-----------------------------------------------------------
[jira] Commented: (FELIXM2-8) Exported Package not found in bundle
or JARs on bundle class path (Feature or Bug ?)
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/FELIXM2-8?page=comments#action_12428136 ]
Richard S. Hall commented on FELIXM2-8:
---------------------------------------
As far as I understand the R3 spec, no re-exporting of package is allowed at all. Page 47 of the R3 spec says, "The Framework must guarantee that classes and resources in the exported package's name-space are loaded from the exporting bundle." So, I think if KF allows this, then it is incorrect.
As for R4, the spec only allows re-exporting of packages using require-bundle, not simply with import and export package. Thus, I think the maven plugin is right to enforce this...of course, it will eventually need to be updated to support require-bundle when it is implemented, but that is another issue. :-)
> Exported Package not found in bundle or JARs on bundle class path (Feature or Bug ?)
> ------------------------------------------------------------------------------------
>
> Key: FELIXM2-8
> URL: http://issues.apache.org/jira/browse/FELIXM2-8
> Project: Felix M2 Plugin
> Issue Type: Bug
> Reporter: Jan S. Rellermeyer
> Assigned To: Timothy Bennett
> Priority: Minor
>
> I have updated to the most recent version of the plugin and it seems that it now performs some checking if exported packages are in the classpath of the bundle that has declared it as export. Correct me, if I am wrong but I know from R3 that is is allowed to (re-) export packages that are imported (very common pattern in Knopflerfish bundles) and I think this is also possible in R4. So maybe the plugin should additionally check (and allow) packages that have been imported.
> Jan.
--
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