Extended Java APIs (javax.xml, e.a.)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Extended Java APIs (javax.xml, e.a.)

Felix Meschberger-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Extended Java APIs (javax.xml, e.a.)

Carsten Ziegeler
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Extended Java APIs (javax.xml, e.a.)

Carsten Ziegeler
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Extended Java APIs (javax.xml, e.a.)

Ian Boston
In reply to this post by Felix Meschberger-3

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
Reply | Threaded
Open this post in threaded view
|

Re: Extended Java APIs (javax.xml, e.a.)

justzzzz
In reply to this post by Felix Meschberger-3
+1



On Wed, Jan 19, 2011 at 9:50 AM, Felix Meschberger <[hidden email]>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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Extended Java APIs (javax.xml, e.a.)

Felix Meschberger-3
In reply to this post by Felix Meschberger-3
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
>


Reply | Threaded
Open this post in threaded view
|

Re: Extended Java APIs (javax.xml, e.a.)

Bertrand Delacretaz
On Thu, Jan 27, 2011 at 11:28 AM, Felix Meschberger <[hidden email]> wrote:
> ...See SLING-1958 [1] and the proposed patch.
>
> WDYT ?

+1

-Bertrand
Reply | Threaded
Open this post in threaded view
|

Re: Extended Java APIs (javax.xml, e.a.)

Carsten Ziegeler
In reply to this post by Felix Meschberger-3
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
[hidden email]