[ 
https://issues.apache.org/jira/browse/SLING-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger updated SLING-2109:
-------------------------------------

    Description: 
Currently a number of Java Extension packages are exported without a version 
from the system bundle; for example javax.transaction.*, or javax.xml,*.

The problem with these packages is that some applications will not want to 
depend on these packages from the environment hence do not want them to be 
exported from the system bundle. Yet, in different contexts like the default 
Sling Launchpad build, we just want them available.

To fix this issue, the following should be done:

  * Remove Activation, Transaction, and XML APIs from the System Bundle Export
  * Create two system extension fragment bundles: (1) for JTA and (2) for XML 
APIs

The javax.activation API is problematic anyway and should probably not be used 
from the environment due to the extension loading mechanism employed by 
default. The JTA and XML API system extension fragment bundles can be replaced 
by real bundles. For example to use JAT inside the OSGi framework the Apache 
Aries Transaction Manager bundle can be deployed instead of the JTA system 
extension fragment.

This is related to SLING-1958 which is about replacing the XML related exports 
from the system with bundles embedding the API in the framework itself and thus 
encapsulating from the environment.

  was:
Currently a number of Java Extension packages are exported without a version 
from the system bundle; for example javax.transaction.*, or javax.xml,*.

The problem with these packages is that some applications will not want to 
depend on these packages from the environment hence do not want them to be 
exported from the system bundle. Yet, in different contexts like the default 
Sling Launchpad build, we just want them available.

To fix this issue, the following should be done:

  * Remove Activation, Transaction, and XML APIs from the System Bundle Export
  * Create two system extension fragment bundles: (1) for JTA and (2) for XML 
APIs

The javax.activation API is problematic anyway and should probably not be used 
from the environment due to the extension loading mechanism employed by 
default. The JTA and XML API system extension fragment bundles can be replaced 
by real bundles. For example to use JAT inside the OSGi framework the Apache 
Aries Transaction Manager bundle can be deployed instead of the JTA system 
extension fragment.

This is related to SLING-1985 which is about replacing the XML related exports 
from the system with bundles embedding the API in the framework itself and thus 
encapsulating from the environment.


> Separate some system bundle provide packages into properties for easier 
> overwrite
> ---------------------------------------------------------------------------------
>
>                 Key: SLING-2109
>                 URL: https://issues.apache.org/jira/browse/SLING-2109
>             Project: Sling
>          Issue Type: Improvement
>          Components: Extensions, Launchpad
>    Affects Versions: Launchpad Base 2.3.0
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>             Fix For: Launchpad Base 2.3.2
>
>
> Currently a number of Java Extension packages are exported without a version 
> from the system bundle; for example javax.transaction.*, or javax.xml,*.
> The problem with these packages is that some applications will not want to 
> depend on these packages from the environment hence do not want them to be 
> exported from the system bundle. Yet, in different contexts like the default 
> Sling Launchpad build, we just want them available.
> To fix this issue, the following should be done:
>   * Remove Activation, Transaction, and XML APIs from the System Bundle Export
>   * Create two system extension fragment bundles: (1) for JTA and (2) for XML 
> APIs
> The javax.activation API is problematic anyway and should probably not be 
> used from the environment due to the extension loading mechanism employed by 
> default. The JTA and XML API system extension fragment bundles can be 
> replaced by real bundles. For example to use JAT inside the OSGi framework 
> the Apache Aries Transaction Manager bundle can be deployed instead of the 
> JTA system extension fragment.
> This is related to SLING-1958 which is about replacing the XML related 
> exports from the system with bundles embedding the API in the framework 
> itself and thus encapsulating from the environment.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to