Well issues i mentionned were to have xalan in the classpath. This
particular issue can be solved but this will not help tomee sadly.
Le 4 avr. 2018 19:48, "Matthew Broadhead"
a écrit :
> could xalan be fixed or has everyone given up on it
> meaning https://issues.apache.org/jira/browse/XALANJ-2
could xalan be fixed or has everyone given up on it
meaning https://issues.apache.org/jira/browse/XALANJ-2540 which has 31
up votes
On 04/04/2018 17:30, Romain Manni-Bucau wrote:
That is why we have that hardcoded dep ATM but in tomee it creates as much
issues for apps not using that featire t
That is why we have that hardcoded dep ATM but in tomee it creates as much
issues for apps not using that featire than it solves problem for others :(
Le 4 avr. 2018 17:24, "Matthew Broadhead"
a écrit :
> i posted these links to the issue. did anyone see them? they seem
> important to the prob
i posted these links to the issue. did anyone see them? they seem
important to the problem
https://stackoverflow.com/questions/6340802/java-xpath-apache-jaxp-implementation-performance
https://blogs.sap.com/2009/12/04/performance-improvements-in-nw-java-applications-with-xml-processing/
On 08/
i bumped into this again yesterday. i still can't upgrade from 7.0.3 to
7.0.4. for some reason 7.0.4 loads up with the error whereas 7.0.3
fails after a webapp is reloaded. hopefully this doesn't mean i can no
longer move forward with any upgrades.
all i am doing is simple xsl transformatio
ok i created an issue https://bz.apache.org/bugzilla/show_bug.cgi?id=61875
On 08/12/2017 16:29, Jeremy Boynes wrote:
On Dec 8, 2017, at 3:58 AM, Matthew Broadhead
wrote:
here is a patch which removes the xalan dependency. but it breaks the
ForEachTagTest.
i notice that every constructor gen
> On Dec 8, 2017, at 3:58 AM, Matthew Broadhead
> wrote:
>
> here is a patch which removes the xalan dependency. but it breaks the
> ForEachTagTest.
> i notice that every constructor generates a JSTLXPathCompiler. could it not
> be a singleton?
Thanks for the patch. I tried applying it but i
here is a patch which removes the xalan dependency. but it breaks the
ForEachTagTest.
i notice that every constructor generates a JSTLXPathCompiler. could it
not be a singleton?
On 07/12/2017 15:08, Matthew Broadhead wrote:
is there any other way to rewrite it so that it doesn't use
DTMManage
is there any other way to rewrite it so that it doesn't use DTMManager?
that would also keep the speed? is it a matter of keeping the object in
memory so that it doesn't have to keep building fragments?
also could i build the old version that doesn't need DTMManager and drop
it in my system to
requires a classloader hack, no other trivial way, and that's why we
removed it from tomee
2017-12-06 14:27 GMT+01:00 Matthew Broadhead :
> is there any way that i can get the correct xalan at runtime?
>
> to recap this is the code that is blowing up for me:
> Reader xsl = new InputStreamReader(fi
is there any way that i can get the correct xalan at runtime?
to recap this is the code that is blowing up for me:
Reader xsl = new InputStreamReader(filepath.openStream());
TransformerFactory transformerfactory = TransformerFactory.newInstance();
StreamSource ssXsl = new StreamSource(xsl);
ssXsl
2017-11-30 16:51 GMT+01:00 Jeremy Boynes :
>> On Nov 30, 2017, at 3:14 AM, Matthew Broadhead
>> wrote:
>>
>> has anything been decided? if i try to redeploy a context in production all
>> my xslt processors blow up. there should be a solution that fits all?
>
> Taglibs (both Apache and Glassfi
> On Nov 30, 2017, at 3:14 AM, Matthew Broadhead
> wrote:
>
> has anything been decided? if i try to redeploy a context in production all
> my xslt processors blow up. there should be a solution that fits all?
Taglibs (both Apache and Glassfish) has always had a dependency on Xalan. My
unde
has anything been decided? if i try to redeploy a context in production
all my xslt processors blow up. there should be a solution that fits all?
On 27/11/2017 20:03, Romain Manni-Bucau wrote:
2017-11-27 20:01 GMT+01:00 Jeremy Boynes :
On Nov 27, 2017, at 7:38 AM, Romain Manni-Bucau wrote:
2017-11-27 20:01 GMT+01:00 Jeremy Boynes :
>> On Nov 27, 2017, at 7:38 AM, Romain Manni-Bucau
>> wrote:
>>
>> 2017-11-27 16:31 GMT+01:00 Jeremy Boynes :
>>> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
>>> wrote:
>>>
>>> In TomEE 7.0.3 everything is fine at startup. But if a webapp is reload
> On Nov 27, 2017, at 7:38 AM, Romain Manni-Bucau
> wrote:
>
> 2017-11-27 16:31 GMT+01:00 Jeremy Boynes :
>> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
>> wrote:
>>
>> In TomEE 7.0.3 everything is fine at startup. But if a webapp is reloaded I
>> get
>> java.lang.ClassCastException: org.
2017-11-27 16:31 GMT+01:00 Jeremy Boynes :
> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
> wrote:
>
> In TomEE 7.0.3 everything is fine at startup. But if a webapp is reloaded I
> get
> java.lang.ClassCastException: org.apache.xml.dtm.ref.DTMManagerDefault
> cannot be cast to org.apache.xml.d
> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
> wrote:
>
> In TomEE 7.0.3 everything is fine at startup. But if a webapp is reloaded I
> get
> java.lang.ClassCastException: org.apache.xml.dtm.ref.DTMManagerDefault cannot
> be cast to org.apache.xml.dtm.DTMManager
> and the whole container
In TomEE 7.0.3 everything is fine at startup. But if a webapp is
reloaded I get
java.lang.ClassCastException: org.apache.xml.dtm.ref.DTMManagerDefault
cannot be cast to org.apache.xml.dtm.DTMManager
and the whole container needs to be restarted which is not ideal during
production
Now in TomE
> On Nov 26, 2017, at 2:17 PM, Matthew Broadhead
> wrote:
>
> So to run the tests I could reverse the changes of the commit and then update
> to javax.xml.* and run tests?
>
> I am still struggling a bit to understand exactly what is happening wrt
> VariableStack and how I can change over to
So to run the tests I could reverse the changes of the commit and then
update to javax.xml.* and run tests?
I am still struggling a bit to understand exactly what is happening wrt
VariableStack and how I can change over to XPathVariableResolver. And
also don't see a way to replace XBoolean, X
On Nov 26, 2017, at 6:32 AM, Matthew Broadhead
wrote:
>
> Hi,
> I am currently evaluating whether the Xalan dependency can be dropped from
> taglibs and replaced with javax.xml.*.
>
> The reason for this is a conflict which occurs when I have Apache Fop as a
> dependency:
> java.lang.ClassCas
Hi,
I am currently evaluating whether the Xalan dependency can be dropped
from taglibs and replaced with javax.xml.*.
The reason for this is a conflict which occurs when I have Apache Fop as
a dependency:
java.lang.ClassCastException: org.apache.xml.dtm.ref.DTMManagerDefault
cannot be cast to
23 matches
Mail list logo
