You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2010/12/13 03:45:19 UTC
DO NOT REPLY [Bug 50462] New: xalan import should not be optional in
maven-bundle-plugin
https://issues.apache.org/bugzilla/show_bug.cgi?id=50462
Summary: xalan import should not be optional in
maven-bundle-plugin
Product: Taglibs
Version: 1.2.0
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Standard Taglib
AssignedTo: dev@tomcat.apache.org
ReportedBy: rwonly@gmail.com
I know the Xalan might be removed in future due to the performance issue:
http://www.mail-archive.com/dev@tomcat.apache.org/msg43586.html
But so far, this seems still a hard dependency.
So I should not made it as optional in maven bundle plugin..
Will provide a patch.
-Rex
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 50462] xalan import should not be optional in
maven-bundle-plugin
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50462
--- Comment #1 from Rex Wang <rw...@gmail.com> 2010-12-12 21:46:47 EST ---
Created an attachment (id=26396)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=26396)
remove optional xalan import
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 50462] xalan import should not be optional in
maven-bundle-plugin
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50462
--- Comment #5 from xiaming <fo...@gmail.com> 2012-01-12 07:53:42 UTC ---
Hi Devs,
Can you make a maven release for taglib 1.2? We want to use this in Geronimo
release. thanks in advance!
Forrest
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 50462] xalan import should not be optional in
maven-bundle-plugin
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50462
Jeremy Boynes <jb...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Jeremy Boynes <jb...@apache.org> 2010-12-31 18:31:40 EST ---
Removed optional declaration in r1054176
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[taglibs] Refactoring XPath support
Posted by Jeremy Boynes <jb...@apache.org>.
I've added a patch to #27717 that changes the XML tags to use Xalan's low-level API directly. This addresses:
1) Most of the performance issues with iteration from #27717
2) Support for position() and last() from #22765 and others
3) Support for using the same variable twice from #49578
which basically clears up the open bugs with the XML taglib
On my machine, iterating 100000 items took 1600ms which seems OK. It still increases with n^2 for some reason I have not figured out.
On Dec 22, 2010, at 7:47 PM, Jeremy Boynes wrote:
>
> On Dec 22, 2010, at 1:01 AM, Rex Wang wrote:
>
>> 2010/12/22 Jeremy Boynes <jb...@apache.org>
>>>
>>> The XPath implementation in Oracle's JDK was originally based on Xalan and
>>> has the same performance issue.
>>>
>>> One issue with the JAXP API is that it does not allow context to be passed
>>> to the evaluation and so the XPath position() and last() functions can't be
>>> supported (at least, I've not figured out how). Now the current
>>> implementation does not support them either (see #22765) so this may not be
>>> a major issue, but the proprietary APIs in Jaxen and JXPath should enable
>>> this (would need to code it to be sure).
>>>
>>> How about:
>>> * define our own API that allows context to be passed
>>> * create a context-free wrapper for JAXP and remove the hard dependency on
>>> Xalan (solving the optional bundle issue)
>>> * create other wrappers for Jaxen and/or JXPath that can use the context
>>> We could proceed with a release based on the first two steps alone as
>>> there's no regression.
>>>
>> +0 if the reason of defining our own api is only to resolve #22765, since it
>> is not required by spec.
>
> Reading the last 2 bullets on pp157 it references context position and size and the only way to access those in XPath would be using the position() and last() functions.
>
>> And, the performance issue is not a blocker to you to do release?
>
> It's been there long enough so no :)
> It's more that if a fix requires changes to the dependencies it's user impacting.
>
> There are still the two issues with the fmt library and 50265 is functionally broken not just a performance issue.
>
>
>
Re: DO NOT REPLY [Bug 50462] xalan import should not be optional in maven-bundle-plugin
Posted by Jeremy Boynes <jb...@apache.org>.
On Dec 22, 2010, at 1:01 AM, Rex Wang wrote:
> 2010/12/22 Jeremy Boynes <jb...@apache.org>
>>
>> The XPath implementation in Oracle's JDK was originally based on Xalan and
>> has the same performance issue.
>>
>> One issue with the JAXP API is that it does not allow context to be passed
>> to the evaluation and so the XPath position() and last() functions can't be
>> supported (at least, I've not figured out how). Now the current
>> implementation does not support them either (see #22765) so this may not be
>> a major issue, but the proprietary APIs in Jaxen and JXPath should enable
>> this (would need to code it to be sure).
>>
>> How about:
>> * define our own API that allows context to be passed
>> * create a context-free wrapper for JAXP and remove the hard dependency on
>> Xalan (solving the optional bundle issue)
>> * create other wrappers for Jaxen and/or JXPath that can use the context
>> We could proceed with a release based on the first two steps alone as
>> there's no regression.
>>
> +0 if the reason of defining our own api is only to resolve #22765, since it
> is not required by spec.
Reading the last 2 bullets on pp157 it references context position and size and the only way to access those in XPath would be using the position() and last() functions.
> And, the performance issue is not a blocker to you to do release?
It's been there long enough so no :)
It's more that if a fix requires changes to the dependencies it's user impacting.
There are still the two issues with the fmt library and 50265 is functionally broken not just a performance issue.
[taglibs] Trying to use JAXP XPath instead of raw Xalan
Posted by Jeremy Boynes <jb...@apache.org>.
On Dec 22, 2010, at 1:01 AM, Rex Wang wrote:
>>>
>>> Why not move to the standard api in jdk instead of defining new apis and
>>> wrappers?
I put together an API to abstract the XPath implementation and tried to use the JAXP XPath support; see
https://issues.apache.org/bugzilla/show_bug.cgi?id=27717#c21
There's a problem in JAXPXPathExpression#evaluateObject() where it needs to return the actual result of evaluating the XPath (boolean, String, Number or "node-set"). However, the XPath API requires you to specify a specific return type:
http://download.oracle.com/javase/6/docs/api/javax/xml/xpath/XPathExpression.html#evaluate(java.lang.Object,%20javax.xml.namespace.QName)
Any ideas on how to work around that would be appreciated, otherwise we will be forced to use a proprietary API.
Cheers
Jeremy
Re: DO NOT REPLY [Bug 50462] xalan import should not be optional in maven-bundle-plugin
Posted by Rex Wang <rw...@gmail.com>.
2010/12/22 Jeremy Boynes <jb...@apache.org>
> On Dec 21, 2010, at 10:28 PM, Rex Wang wrote:
>
> > 2010/12/22 Jeremy Boynes <jb...@apache.org>
> >>
> >> Perhaps the changes needed to address the performance issue in #27717
> are
> >> relevant here.
> >> These stem from issues in Xalan's implementation which would also apply
> if
> >> we tried to use the JDK's implementation. I had a prototype working with
> >> Jaxen but the project is pushing builds to the Maven repos and does not
> seem
> >> very active (like, no-one replied to a recent committer call) so
> depending
> >> on it could be problematic. I was thinking of using JXPath instead (from
> >> commons).
> >>
> > I also don't find JXPATH in maven repo.. However, you also can use the
> > servicemix bundled one:
> >
> http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.commons-jxpath
> ,
> > But that is not the least version 1.3.
>
> The official one is at:
> http://repo2.maven.org/maven2/commons-jxpath/commons-jxpath/1.3/
>
> Not sure if it's an OSGi bundle though.
>
I just saw it. Yes, it is a bundle. But seems made 2 years ago. Is jxpath
actively maintained now?
Is that what ServiceMix is doing when repackaging?
>
Yes.
> >
> >
> >>
> >> With multiple options out there, perhaps we could just have taglibs use
> an
> >> interface and provide wrappers for each as separate modules. if we did
> that,
> >> is that something that could be easily handled with OSGi?
> >>
> >
> > I am not very familiar with XPATH. Do you mean the approach like spi?
> > IIUC, xalan implements the spi of javax.xml.transform.TransformerFactory
> and
> > javax.xml.xpath.XPathFactory. So if xalan is in the path, we can choose
> it
> > as the xpath implementation. I am not sure if jaxen and jxpath implement
> the
> > spi either.
> > Why not move to the standard api in jdk instead of defining new apis and
> > wrappers?
>
> The XPath implementation in Oracle's JDK was originally based on Xalan and
> has the same performance issue.
>
> One issue with the JAXP API is that it does not allow context to be passed
> to the evaluation and so the XPath position() and last() functions can't be
> supported (at least, I've not figured out how). Now the current
> implementation does not support them either (see #22765) so this may not be
> a major issue, but the proprietary APIs in Jaxen and JXPath should enable
> this (would need to code it to be sure).
>
> How about:
> * define our own API that allows context to be passed
> * create a context-free wrapper for JAXP and remove the hard dependency on
> Xalan (solving the optional bundle issue)
> * create other wrappers for Jaxen and/or JXPath that can use the context
> We could proceed with a release based on the first two steps alone as
> there's no regression.
>
+0 if the reason of defining our own api is only to resolve #22765, since it
is not required by spec.
And, the performance issue is not a blocker to you to do release?
Thanks
-Rex
> --
> Jeremy
>
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: DO NOT REPLY [Bug 50462] xalan import should not be optional in maven-bundle-plugin
Posted by Jeremy Boynes <jb...@apache.org>.
On Dec 21, 2010, at 10:28 PM, Rex Wang wrote:
> 2010/12/22 Jeremy Boynes <jb...@apache.org>
>>
>> Perhaps the changes needed to address the performance issue in #27717 are
>> relevant here.
>> These stem from issues in Xalan's implementation which would also apply if
>> we tried to use the JDK's implementation. I had a prototype working with
>> Jaxen but the project is pushing builds to the Maven repos and does not seem
>> very active (like, no-one replied to a recent committer call) so depending
>> on it could be problematic. I was thinking of using JXPath instead (from
>> commons).
>>
> I also don't find JXPATH in maven repo.. However, you also can use the
> servicemix bundled one:
> http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.commons-jxpath,
> But that is not the least version 1.3.
The official one is at:
http://repo2.maven.org/maven2/commons-jxpath/commons-jxpath/1.3/
Not sure if it's an OSGi bundle though. Is that what ServiceMix is doing when repackaging?
>
>
>>
>> With multiple options out there, perhaps we could just have taglibs use an
>> interface and provide wrappers for each as separate modules. if we did that,
>> is that something that could be easily handled with OSGi?
>>
>
> I am not very familiar with XPATH. Do you mean the approach like spi?
> IIUC, xalan implements the spi of javax.xml.transform.TransformerFactory and
> javax.xml.xpath.XPathFactory. So if xalan is in the path, we can choose it
> as the xpath implementation. I am not sure if jaxen and jxpath implement the
> spi either.
> Why not move to the standard api in jdk instead of defining new apis and
> wrappers?
The XPath implementation in Oracle's JDK was originally based on Xalan and has the same performance issue.
One issue with the JAXP API is that it does not allow context to be passed to the evaluation and so the XPath position() and last() functions can't be supported (at least, I've not figured out how). Now the current implementation does not support them either (see #22765) so this may not be a major issue, but the proprietary APIs in Jaxen and JXPath should enable this (would need to code it to be sure).
How about:
* define our own API that allows context to be passed
* create a context-free wrapper for JAXP and remove the hard dependency on Xalan (solving the optional bundle issue)
* create other wrappers for Jaxen and/or JXPath that can use the context
We could proceed with a release based on the first two steps alone as there's no regression.
--
Jeremy
Re: DO NOT REPLY [Bug 50462] xalan import should not be optional in maven-bundle-plugin
Posted by Rex Wang <rw...@gmail.com>.
2010/12/22 Jeremy Boynes <jb...@apache.org>
> On Dec 21, 2010, at 6:15 PM, bugzilla@apache.org wrote:
>
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=50462
> >
> > --- Comment #3 from Rex Wang <rw...@gmail.com> 2010-12-21 21:15:19 EST
> ---
> > (In reply to comment #2)
> >> It's marked optional in Maven as it is only needed if someone is using
> the XML
> >> tags.
> >>
> >> Is there a way to mimic that with the OSGi references?
> >
> > Not sure about that.
> >
> > At least, IMO, that is not the correct way by using optional:=resolution
> in
> > import-package to achieve the requirement.
> >
> > I think the optional:=resolution directive is used to express that if
> osgi
> > framework can not resolve the package, the codes in this bundle may use
> the
> > implementation from itself or from jdk.
> >
> > So if the codes have hard dependency to (explicitly import) a package, we
> > should not make it as optional resolution.
>
> Perhaps the changes needed to address the performance issue in #27717 are
> relevant here.
> These stem from issues in Xalan's implementation which would also apply if
> we tried to use the JDK's implementation. I had a prototype working with
> Jaxen but the project is pushing builds to the Maven repos and does not seem
> very active (like, no-one replied to a recent committer call) so depending
> on it could be problematic. I was thinking of using JXPath instead (from
> commons).
>
I also don't find JXPATH in maven repo.. However, you also can use the
servicemix bundled one:
http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.commons-jxpath,
But that is not the least version 1.3.
>
> With multiple options out there, perhaps we could just have taglibs use an
> interface and provide wrappers for each as separate modules. if we did that,
> is that something that could be easily handled with OSGi?
>
I am not very familiar with XPATH. Do you mean the approach like spi?
IIUC, xalan implements the spi of javax.xml.transform.TransformerFactory and
javax.xml.xpath.XPathFactory. So if xalan is in the path, we can choose it
as the xpath implementation. I am not sure if jaxen and jxpath implement the
spi either.
Why not move to the standard api in jdk instead of defining new apis and
wrappers?
-Rex
>
> Thanks
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: DO NOT REPLY [Bug 50462] xalan import should not be optional in maven-bundle-plugin
Posted by Jeremy Boynes <jb...@apache.org>.
On Dec 21, 2010, at 6:15 PM, bugzilla@apache.org wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50462
>
> --- Comment #3 from Rex Wang <rw...@gmail.com> 2010-12-21 21:15:19 EST ---
> (In reply to comment #2)
>> It's marked optional in Maven as it is only needed if someone is using the XML
>> tags.
>>
>> Is there a way to mimic that with the OSGi references?
>
> Not sure about that.
>
> At least, IMO, that is not the correct way by using optional:=resolution in
> import-package to achieve the requirement.
>
> I think the optional:=resolution directive is used to express that if osgi
> framework can not resolve the package, the codes in this bundle may use the
> implementation from itself or from jdk.
>
> So if the codes have hard dependency to (explicitly import) a package, we
> should not make it as optional resolution.
Perhaps the changes needed to address the performance issue in #27717 are relevant here.
These stem from issues in Xalan's implementation which would also apply if we tried to use the JDK's implementation. I had a prototype working with Jaxen but the project is pushing builds to the Maven repos and does not seem very active (like, no-one replied to a recent committer call) so depending on it could be problematic. I was thinking of using JXPath instead (from commons).
With multiple options out there, perhaps we could just have taglibs use an interface and provide wrappers for each as separate modules. if we did that, is that something that could be easily handled with OSGi?
Thanks
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 50462] xalan import should not be optional in
maven-bundle-plugin
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50462
--- Comment #3 from Rex Wang <rw...@gmail.com> 2010-12-21 21:15:19 EST ---
(In reply to comment #2)
> It's marked optional in Maven as it is only needed if someone is using the XML
> tags.
>
> Is there a way to mimic that with the OSGi references?
Not sure about that.
At least, IMO, that is not the correct way by using optional:=resolution in
import-package to achieve the requirement.
I think the optional:=resolution directive is used to express that if osgi
framework can not resolve the package, the codes in this bundle may use the
implementation from itself or from jdk.
So if the codes have hard dependency to (explicitly import) a package, we
should not make it as optional resolution.
-Rex
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 50462] xalan import should not be optional in
maven-bundle-plugin
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50462
--- Comment #2 from Jeremy Boynes <jb...@apache.org> 2010-12-19 12:33:57 EST ---
It's marked optional in Maven as it is only needed if someone is using the XML
tags.
Is there a way to mimic that with the OSGi references?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 50462] xalan import should not be optional in
maven-bundle-plugin
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50462
Jeremy Boynes <jb...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |50064
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org