You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@adobe.com> on 2011/01/19 15:50:01 UTC
Extended Java APIs (javax.xml, e.a.)
Hi all,
We currently add a whole bunch of Java Extension APIs in the javax.*
arena to the export list of the system bundle by virtue of actually
providing in the framework, what is provided in the JDK.
While we (at Adobe) are now confronted with real-life use of such API
(javax.xml, etc.) we run in to a number of issues, like class loading
but also incompleteness of the API packages provided by the platform.
I am thus considering the following as a potential idea:
* We remove the extension API (mostly around XML and DOM stuff)
from the sling.properties file and thus do not by default
provide it in the framework any longer
* As a replacement we create a system extension fragment bundle
which re-adds these packages
* For more demanding applications the fragment bundle can be
replaced with a bundle containing and exporting the full API
packages -- thus effectively hiding what is provided by platform.
WDYT ?
Regards
Felix
Re: Extended Java APIs (javax.xml, e.a.)
Posted by Carsten Ziegeler <cz...@apache.org>.
Related topic: do we need to list the whole packages coming from the jre
in the sling.properties anyway? The framework comes with default values
afaik.
Regards
Carsten
Carsten Ziegeler wrote
> Felix Meschberger wrote
>> Hi all,
>>
>> We currently add a whole bunch of Java Extension APIs in the javax.*
>> arena to the export list of the system bundle by virtue of actually
>> providing in the framework, what is provided in the JDK.
>>
>> While we (at Adobe) are now confronted with real-life use of such API
>> (javax.xml, etc.) we run in to a number of issues, like class loading
>> but also incompleteness of the API packages provided by the platform.
>>
>> I am thus considering the following as a potential idea:
>>
>> * We remove the extension API (mostly around XML and DOM stuff)
>> from the sling.properties file and thus do not by default
>> provide it in the framework any longer
>> * As a replacement we create a system extension fragment bundle
>> which re-adds these packages
>> * For more demanding applications the fragment bundle can be
>> replaced with a bundle containing and exporting the full API
>> packages -- thus effectively hiding what is provided by platform.
>>
> Can you give a list of the packages we're talking about here?
>
> Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Extended Java APIs (javax.xml, e.a.)
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote
> Hi all,
>
> We currently add a whole bunch of Java Extension APIs in the javax.*
> arena to the export list of the system bundle by virtue of actually
> providing in the framework, what is provided in the JDK.
>
> While we (at Adobe) are now confronted with real-life use of such API
> (javax.xml, etc.) we run in to a number of issues, like class loading
> but also incompleteness of the API packages provided by the platform.
>
> I am thus considering the following as a potential idea:
>
> * We remove the extension API (mostly around XML and DOM stuff)
> from the sling.properties file and thus do not by default
> provide it in the framework any longer
> * As a replacement we create a system extension fragment bundle
> which re-adds these packages
> * For more demanding applications the fragment bundle can be
> replaced with a bundle containing and exporting the full API
> packages -- thus effectively hiding what is provided by platform.
>
Can you give a list of the packages we're talking about here?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Extended Java APIs (javax.xml, e.a.)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jan 27, 2011 at 11:28 AM, Felix Meschberger <fm...@adobe.com> wrote:
> ...See SLING-1958 [1] and the proposed patch.
>
> WDYT ?
+1
-Bertrand
Re: Extended Java APIs (javax.xml, e.a.)
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote
> Hi,
>
> Well, I have been experimenting with the Apache ServiceMix wrapper
> bundles and was successful. So I think, instead of actually creating
> some system bundle fragments for the XML APIs we should probably rather
> add the ServiceMix bundle(s) from the start.
>
> See SLING-1958 [1] and the proposed patch.
>
> WDYT ?
Yes, this sounds like the best approach: +1
Carsten
>
> Regards
> Felix
>
> [1] https://issues.apache.org/jira/browse/SLING-1958
>
> Am Mittwoch, den 19.01.2011, 14:50 +0000 schrieb Felix Meschberger:
>> Hi all,
>>
>> We currently add a whole bunch of Java Extension APIs in the javax.*
>> arena to the export list of the system bundle by virtue of actually
>> providing in the framework, what is provided in the JDK.
>>
>> While we (at Adobe) are now confronted with real-life use of such API
>> (javax.xml, etc.) we run in to a number of issues, like class loading
>> but also incompleteness of the API packages provided by the platform.
>>
>> I am thus considering the following as a potential idea:
>>
>> * We remove the extension API (mostly around XML and DOM stuff)
>> from the sling.properties file and thus do not by default
>> provide it in the framework any longer
>> * As a replacement we create a system extension fragment bundle
>> which re-adds these packages
>> * For more demanding applications the fragment bundle can be
>> replaced with a bundle containing and exporting the full API
>> packages -- thus effectively hiding what is provided by platform.
>>
>> WDYT ?
>>
>> Regards
>> Felix
>>
>
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Extended Java APIs (javax.xml, e.a.)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Well, I have been experimenting with the Apache ServiceMix wrapper
bundles and was successful. So I think, instead of actually creating
some system bundle fragments for the XML APIs we should probably rather
add the ServiceMix bundle(s) from the start.
See SLING-1958 [1] and the proposed patch.
WDYT ?
Regards
Felix
[1] https://issues.apache.org/jira/browse/SLING-1958
Am Mittwoch, den 19.01.2011, 14:50 +0000 schrieb Felix Meschberger:
> Hi all,
>
> We currently add a whole bunch of Java Extension APIs in the javax.*
> arena to the export list of the system bundle by virtue of actually
> providing in the framework, what is provided in the JDK.
>
> While we (at Adobe) are now confronted with real-life use of such API
> (javax.xml, etc.) we run in to a number of issues, like class loading
> but also incompleteness of the API packages provided by the platform.
>
> I am thus considering the following as a potential idea:
>
> * We remove the extension API (mostly around XML and DOM stuff)
> from the sling.properties file and thus do not by default
> provide it in the framework any longer
> * As a replacement we create a system extension fragment bundle
> which re-adds these packages
> * For more demanding applications the fragment bundle can be
> replaced with a bundle containing and exporting the full API
> packages -- thus effectively hiding what is provided by platform.
>
> WDYT ?
>
> Regards
> Felix
>
Re: Extended Java APIs (javax.xml, e.a.)
Posted by Justin Edelson <ju...@justinedelson.com>.
+1
On Wed, Jan 19, 2011 at 9:50 AM, Felix Meschberger <fm...@adobe.com>wrote:
> Hi all,
>
> We currently add a whole bunch of Java Extension APIs in the javax.*
> arena to the export list of the system bundle by virtue of actually
> providing in the framework, what is provided in the JDK.
>
> While we (at Adobe) are now confronted with real-life use of such API
> (javax.xml, etc.) we run in to a number of issues, like class loading
> but also incompleteness of the API packages provided by the platform.
>
> I am thus considering the following as a potential idea:
>
> * We remove the extension API (mostly around XML and DOM stuff)
> from the sling.properties file and thus do not by default
> provide it in the framework any longer
> * As a replacement we create a system extension fragment bundle
> which re-adds these packages
> * For more demanding applications the fragment bundle can be
> replaced with a bundle containing and exporting the full API
> packages -- thus effectively hiding what is provided by platform.
>
> WDYT ?
>
> Regards
> Felix
>
>
Re: Extended Java APIs (javax.xml, e.a.)
Posted by Ian Boston <ie...@tfd.co.uk>.
On 19 Jan 2011, at 14:50, Felix Meschberger wrote:
> * For more demanding applications the fragment bundle can be
> replaced with a bundle containing and exporting the full API
> packages -- thus effectively hiding what is provided by platform.
I believe this is what we have done already, some of the packages we depended on at one time (EclipseLink JPA) demanded quite a lot of javax.xml.*. IIRC it wasn't at all painful.
Ian