[MGNLDIFF-9] Package includes xerces libs Created: 27/Jan/11  Updated: 27/Sep/11  Resolved: 27/Sep/11

Status: Closed
Project: Magnolia Diff Module
Component/s: None
Affects Version/s: 1.0.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Teresa Miyar Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
is causing MAGNOLIA-3502 I cant install magnolia Author 4.4 on... Closed
duplicate
is duplicated by MGNLDIFF-8 bundled daisy diff jar should not inc... Closed
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

I am increasing the priority. This especially causes problems on jboss installations but might cause similar problems which then might be difficult to chase down.



 Comments   
Comment by Zdenek Skodik [ 11/Mar/11 ]

This is the issue only for JBoss community edition, with enterprise one it doesn't occur as Lee Haslup from CSC let us kindly know:

One thing that might be interesting to you – and something that has slowed us down – is that we find we can successfully deploy Magnolia 4.4 to the JBoss Enterprise edition with the daisyDiff jars in place and it works fine. Whatever the problem is with the classloader and daisyDiff, it only happens for us on the JBoss community edition servers. We run the Enterprise version of JBoss 5.0.1 on our production and test servers and have been running Magnolia 4.4 with the Diff module in place (but with the xercesImpl jar deleted) for a long time on that server and it works fine. One of the reasons it took us so long to try deleting the daisyDiff jar and the diff module is that those jars are running fine on the test server with the same version numbers of JBoss and Magnolia (but with an EE version of JBoss on the server). We were using our JBoss 5.0.1 deployment of Magnolia on the test server as an example of how it should be done and it just wouldn't work for us.

Generated at Mon Feb 12 05:20:28 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.