OSGi support for 2.10.0

[Holger Hoffstaette <ho...@googlemail.com>]

Hi,

I'm very glad that Xerces-J is showing signs of life and gearing for a
2.10 release. I know it's a bit late in the release cycle, but I'd like to
contribute an IMHO very important piece: proper OSGi integration.

The recently released OSGi spec 4.2 has support for proper registration of
JAXP-compliant parsers into the OSGi service registry. This integration is
extremely minimal and requires merely two things:

- addition of a single ready-made class (a bundle activator)
- addition of a handful of entries to the MANIFEST file

That's all. While the single new class has a compile-time dependency on
the OSGi framework, it is only a *compile* dependency that has no impact
on the run-time behaviour of xerces outside of OSGi; users will likely not
even see it as it can be made as "private" as possible.

The process for adding this integration is explained in the 4.2 Compendium
and Enterprise specs which are freely available from www.osgi.org.

The necessary additions to the build took me ~10 minutes - all I did was
add the Activator (available as source under ASL license), an Apache Felix
framework jar as OSGi compile-time dependency, and the necessary bundle
headers to the manifest.xerces.

These additions have no impact on non-OSGi users, license restrictions,
runtime overhead or any other effect that would "endanger" a release or the
stability of the code. Therefore I'd really like to see this considered
for the upcoming release...pleeease? :)

If this is of interest I'll file a JIRA and attach patches & instructions
there.

Holger



---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: OSGi support for 2.10.0

[Holger Hoffstaette <ho...@googlemail.com>]

On Mon, 05 Jul 2010 14:36:28 -0400, Michael Glavassevich wrote:

> "Holger Hoffstaette" <ho...@googlemail.com> wrote on
> 06/10/2010 11:09:07 PM:
>> Turns out that after fixing that it happily explodes because
>> DeferredDocumentImpl pulls in ElementTraversal - which doesn't exist in
>> the JDK - and it's all downhill from there. I thought I'd get by without
>> the new SAX/DOM APIs but apparently not..at least that explains the
>> somewhat weird dependencies in SpringSource's xml-commons bundle.
> 
> I'm not familiar with the issue. What would need to be done in xml-commons
> and why?

I (probably) "only" would have needed to bundle xml-commons with a proper
version and then import them as well, so that xerces does not see
the JDK interfaces. However that seems fraught with problems because of
the existing class loading, JAXP activation etc. in xml-apis.

Other than that..the entire trifecta of xml-apis/xerces/xalan
and their cross-dependencies is hopeless in their current state. Coupling
JAXP activation and SAX/DOM interfaces, xalan depending on internal xerces
classes.. I pretty much lost interest after checking out all three
projects and getting them into eclipse.

-h



---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: OSGi support for 2.10.0

[Michael Glavassevich <mr...@ca.ibm.com>]

Hi Holger,

"Holger Hoffstaette" <ho...@googlemail.com> wrote on
06/10/2010 11:09:07 PM:

> On Thu, 10 Jun 2010 19:20:23 -0400, Michael Glavassevich wrote:
>
> >> Well there really are several different aspects to the problem,
> >> unfortunately some caused by the completely broken-by-design JAXP
> >> mechanism ...
> >
> > It has its problems but it is the standard and would need a new
revision
> > of the specification to improve it if that's even possible at this
point.
> > Any change / enhancement would have to be backwards compatible with the
> > current JAXP spec. Then there's all the other APIs (e.g. StAX, JAXB,
>
> That much is clear, and I wouldn't expect otherwise (I'm familiar with
the
> whole drama). That being said..
>
> >> The patch I have so far addresses exactly one use case. I'll file a
JIRA
> >> tomorrow.
>
> ..I'll now have to put my foot in my mouth :P
>
> As proof that parsing actually works I just spent a few hours writing a
> nifty little interactive showcase (based on the new OSGi shell commands)
> that dynamically finds/uses/switches between any found
> DOMBuilderFactories, and only had it "working" because of a silly bug.
> Turns out that after fixing that it happily explodes because
> DeferredDocumentImpl pulls in ElementTraversal - which doesn't exist in
> the JDK - and it's all downhill from there. I thought I'd get by without
> the new SAX/DOM APIs but apparently not..at least that explains the
> somewhat weird dependencies in SpringSource's xml-commons bundle.
>
> I guess I'll file the JIRA anyway and attach what I have so far,
including
> the example and some problem descriptions. Seems like it really has to be
> addressed in xml-commons first. "any help appreciated" :)

I'm not familiar with the issue. What would need to be done in xml-commons
and why?

> Holger
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Re: OSGi support for 2.10.0

[Holger Hoffstaette <ho...@googlemail.com>]

On Thu, 10 Jun 2010 19:20:23 -0400, Michael Glavassevich wrote:

>> Well there really are several different aspects to the problem,
>> unfortunately some caused by the completely broken-by-design JAXP
>> mechanism ...
> 
> It has its problems but it is the standard and would need a new revision
> of the specification to improve it if that's even possible at this point.
> Any change / enhancement would have to be backwards compatible with the
> current JAXP spec. Then there's all the other APIs (e.g. StAX, JAXB,

That much is clear, and I wouldn't expect otherwise (I'm familiar with the
whole drama). That being said..

>> The patch I have so far addresses exactly one use case. I'll file a JIRA
>> tomorrow.

..I'll now have to put my foot in my mouth :P

As proof that parsing actually works I just spent a few hours writing a
nifty little interactive showcase (based on the new OSGi shell commands)
that dynamically finds/uses/switches between any found
DOMBuilderFactories, and only had it "working" because of a silly bug.
Turns out that after fixing that it happily explodes because
DeferredDocumentImpl pulls in ElementTraversal - which doesn't exist in
the JDK - and it's all downhill from there. I thought I'd get by without
the new SAX/DOM APIs but apparently not..at least that explains the
somewhat weird dependencies in SpringSource's xml-commons bundle.

I guess I'll file the JIRA anyway and attach what I have so far, including
the example and some problem descriptions. Seems like it really has to be
addressed in xml-commons first. "any help appreciated" :)

Holger



---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: OSGi support for 2.10.0

[Michael Glavassevich <mr...@ca.ibm.com>]

Hi Holger,

"Holger Hoffstaette" <ho...@googlemail.com> wrote on
06/10/2010 04:37:17 PM:

> First of all thanks for the interest, all. Apologies for not answering
> earlier, got pulled away..
>
> On Thu, 03 Jun 2010 00:38:49 -0400, Michael Glavassevich wrote:
> > I did commit a bug fix today, but we really are trying to get a build
and
> > testing done right now, along with the remaining doc updates. Khaled
did
>
> Understood.
>
> > propose another release for later in the year, so perhaps OSGi support
> > could be part of that and would also give folks ample time to reflect
on
>
> Sounds good.
>
> > the feature, rather than rushing something new in without a good
> > understanding of what it is / does and its implications.
>
> Well there really are several different aspects to the problem,
> unfortunately some caused by the completely broken-by-design JAXP
> mechanism ...

It has its problems but it is the standard and would need a new revision of
the specification to improve it if that's even possible at this point. Any
change / enhancement would have to be backwards compatible with the current
JAXP spec. Then there's all the other APIs (e.g. StAX, JAXB, JAX-WS,
etc...) which have adopted similar patterns. If the Java platform had a
modularization story earlier in the game (and not just thinking about
introducing it now in Java 7) there might have been more hope for a better
design.

> ... and bad programming practices by applications. These need to be
> addressed separately, probably in xml-commons (I've looked at the
> FactoryFinder). But one problem at a time..
>
> The patch I have so far addresses exactly one use case. I'll file a JIRA
> tomorrow.
>
> thanks
> Holger
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org

Thanks.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Re: OSGi support for 2.10.0

[Holger Hoffstaette <ho...@googlemail.com>]

First of all thanks for the interest, all. Apologies for not answering
earlier, got pulled away..

On Thu, 03 Jun 2010 00:38:49 -0400, Michael Glavassevich wrote:
> I did commit a bug fix today, but we really are trying to get a build and
> testing done right now, along with the remaining doc updates. Khaled did

Understood.

> propose another release for later in the year, so perhaps OSGi support
> could be part of that and would also give folks ample time to reflect on

Sounds good.

> the feature, rather than rushing something new in without a good
> understanding of what it is / does and its implications.

Well there really are several different aspects to the problem,
unfortunately some caused by the completely broken-by-design JAXP
mechanism and bad programming practices by applications. These need to be
addressed separately, probably in xml-commons (I've looked at the
FactoryFinder). But one problem at a time..

The patch I have so far addresses exactly one use case. I'll file a JIRA
tomorrow.

thanks
Holger



---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

Re: OSGi support for 2.10.0

[Michael Glavassevich <mr...@ca.ibm.com>]

Hiranya Jayathilaka <hi...@gmail.com> wrote on 06/02/2010 11:54:02 PM:

>> On Thu, Jun 3, 2010 at 1:06 AM, Holger Hoffstaette <
>> holger.hoffstaette@googlemail.com> wrote:
>>
>> Hi,
>>
>> I'm very glad that Xerces-J is showing signs of life and gearing for a
>> 2.10 release. I know it's a bit late in the release cycle, but I'd like
to
>> contribute an IMHO very important piece: proper OSGi integration.
>>
>> The recently released OSGi spec 4.2 has support for proper registration
of
>> JAXP-compliant parsers into the OSGi service registry. This integration
is
>> extremely minimal and requires merely two things:
>>
>> - addition of a single ready-made class (a bundle activator)
>> - addition of a handful of entries to the MANIFEST file
>>
>> That's all. While the single new class has a compile-time dependency on
>> the OSGi framework, it is only a *compile* dependency that has no impact
>> on the run-time behaviour of xerces outside of OSGi; users will likely
not
>> even see it as it can be made as "private" as possible.
>>
>> The process for adding this integration is explained in the 4.2
Compendium
>> and Enterprise specs which are freely available from www.osgi.org.
>>
>> The necessary additions to the build took me ~10 minutes - all I did was
>> add the Activator (available as source under ASL license), an Apache
Felix
>> framework jar as OSGi compile-time dependency, and the necessary bundle
>> headers to the manifest.xerces.
>>
>> These additions have no impact on non-OSGi users, license restrictions,
>> runtime overhead or any other effect that would "endanger" a release or
the
>> stability of the code. Therefore I'd really like to see this considered
>> for the upcoming release...pleeease? :)
>>
>
> I'm not sure if we can get this into the upcoming release at this
> point. But I'd certainly like to have a look at your patch. So
> please file a JIRA and attach the patch. Xerces usually causes a lot
> of problems when integrating into OSGi environments. So this would
> be a very good improvement.

I did commit a bug fix today, but we really are trying to get a build and
testing done right now, along with the remaining doc updates. Khaled did
propose another release for later in the year, so perhaps OSGi support
could be part of that and would also give folks ample time to reflect on
the feature, rather than rushing something new in without a good
understanding of what it is / does and its implications.

> Thanks,
> Hiranya,
>
>
>> If this is of interest I'll file a JIRA and attach patches &
instructions
>> there.
>>
>> Holger
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
> --
> Hiranya Jayathilaka
> Senior Software Engineer;
> WSO2 Inc.;  http://wso2.org
> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com

Thanks.>

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

Re: OSGi support for 2.10.0

[Hiranya Jayathilaka <hi...@gmail.com>]

Hi Holger,

On Thu, Jun 3, 2010 at 1:06 AM, Holger Hoffstaette <
holger.hoffstaette@googlemail.com> wrote:

>
> Hi,
>
> I'm very glad that Xerces-J is showing signs of life and gearing for a
> 2.10 release. I know it's a bit late in the release cycle, but I'd like to
> contribute an IMHO very important piece: proper OSGi integration.
>
> The recently released OSGi spec 4.2 has support for proper registration of
> JAXP-compliant parsers into the OSGi service registry. This integration is
> extremely minimal and requires merely two things:
>
> - addition of a single ready-made class (a bundle activator)
> - addition of a handful of entries to the MANIFEST file
>
> That's all. While the single new class has a compile-time dependency on
> the OSGi framework, it is only a *compile* dependency that has no impact
> on the run-time behaviour of xerces outside of OSGi; users will likely not
> even see it as it can be made as "private" as possible.
>
> The process for adding this integration is explained in the 4.2 Compendium
> and Enterprise specs which are freely available from www.osgi.org.
>
> The necessary additions to the build took me ~10 minutes - all I did was
> add the Activator (available as source under ASL license), an Apache Felix
> framework jar as OSGi compile-time dependency, and the necessary bundle
> headers to the manifest.xerces.
>
> These additions have no impact on non-OSGi users, license restrictions,
> runtime overhead or any other effect that would "endanger" a release or the
> stability of the code. Therefore I'd really like to see this considered
> for the upcoming release...pleeease? :)
>

I'm not sure if we can get this into the upcoming release at this point. But
I'd certainly like to have a look at your patch. So please file a JIRA and
attach the patch. Xerces usually causes a lot of problems when integrating
into OSGi environments. So this would be a very good improvement.

Thanks,
Hiranya


> If this is of interest I'll file a JIRA and attach patches & instructions
> there.
>
> Holger
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
>


-- 
Hiranya Jayathilaka
Senior Software Engineer;
WSO2 Inc.;  http://wso2.org
E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com