Re: [Mav-user] Help - falling into 'jar hell' with Mav and JDOM
Hi I was looking for a lightweight struts and by chance found this project. Unfortunately I have got a problem with conflicting jdom versions. I saw in the archive that there was a discussion about this last november. What happend to the idea of a 2.2.4 release? Cheers mike > What are the thoughts of updating the jdom dependency of maverick? > If there are no objections I will do the updates and do a > 2.2.4 release. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click [INVALID FOOTER]
Re: [Mav-user] Help - falling into 'jar hell' with Mav and JDOM]
Hi I was looking for a lightweight struts and by chance found this project. Unfortunately I have got a problem with conflicting jdom versions. I saw in the archive that there was a discussion about this last november. What happend to the idea of a 2.2.4 release? Cheers mike > What are the thoughts of updating the jdom dependency of maverick? > If there are no objections I will do the updates and do a > 2.2.4 release. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar [INVALID FOOTER]
Re: [Mav-user] Help - falling into 'jar hell' with Mav and JDOM
Hi -- I think upgrading the jdom library is a good idea -- keeping up-to-date with libraries is a worthy goal. Velocity 1.4 has a dependency on the older jdom as well. This means that us Mav/Velocity users must simultaneously upgrade Velocity to an as of yet unreleased Velocity 1.5. -- Dan At 01:22 AM 11/27/2004, Mike Moulton wrote: Responses inline... I've had a look at changing Maverick to use jdom 1.0, but as I've never used jdom myself, I am unsure what the changes should be and their implications. I've identified the three place in the Maverick code that need altered. #1 should be fine but I need help on #2 and #3. See below for what I've done so far, with some in-line comments. I gleaned most information from changes.txt in the jdom 1.0 distribution. #1 and #3 look good. See notes by #2. #2 org.infohazard.maverick.util.XML.java public static Map getParams(Element node) { ... if (value == null) { /* OLD CODE: Checks for presence of children if no value present * getChildren() now removed from v1.0 if (paramNode.hasChildren()) value = paramNode.getChildren(); else value = paramNode.getTextTrim(); */ /* NEW CODE: Since this method expects what the name/value pair * param nodes should look like (from this methods javadoc), is there * actually any need to check for child elements? */ value = paramNode.getTextTrim(); } Though the javadocs say the that a param should only look like , there has been support for child elements inside a for a while. Not sure about others, but I know I have used this 'feature' many times in the past. With that being the case I would do something like this for #2. List paramChildren = paramNode.getChildren(); if (!paramChildren.isEmpty()) value = paramChildren; else value = paramNode.getTextTrim(); What are the thoughts of updating the jdom dependency of maverick? If there are no objections I will do the updates and do a 2.2.4 release. -- Mike : mike moulton : meltmedia : 1429 north 1st street : phoenix az 85004 : : [EMAIL PROTECTED] : mmoulton66| aim : 602.340.9440 | ofc : 602.432.2568 | cel : 602.340.1003 | fax : : meltmedia.com --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ [INVALID FOOTER] --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ [INVALID FOOTER]
Re: [Mav-user] Help - falling into 'jar hell' with Mav and JDOM
Regarding #2, I agree with your code changes. This is exactly what I originally had (honest!) but missed the trick with child elements and was trying to avoid the potentially unnecessary List creation. I agree on the List creation, however I don't see a way around it given the API changes. Mike, have you had the chance to test #3 against some of the more esoteric uses of the mav xml file? My personal usage is fairly straightforward, so if other users could give some feedback on this to ensure we don't break anything... #3 only effects the use of the maverick config command (command used to display the mav.xml file; used during development). I see no problems with your code change. Obviously, if all is well, I vote for these changes in a new release. I will let the list know once a release is available. -- Mike : mike moulton : meltmedia : 1429 north 1st street : phoenix az 85004 : : [EMAIL PROTECTED] : mmoulton66| aim : 602.340.9440 | ofc : 602.432.2568 | cel : 602.340.1003 | fax : : meltmedia.com --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ [INVALID FOOTER]
Re: [Mav-user] Help - falling into 'jar hell' with Mav and JDOM
Thanks Mike, Regarding #2, I agree with your code changes. This is exactly what I originally had (honest!) but missed the trick with child elements and was trying to avoid the potentially unnecessary List creation. Mike, have you had the chance to test #3 against some of the more esoteric uses of the mav xml file? My personal usage is fairly straightforward, so if other users could give some feedback on this to ensure we don't break anything... Obviously, if all is well, I vote for these changes in a new release. David Mike Moulton wrote: Responses inline... I've had a look at changing Maverick to use jdom 1.0, but as I've never used jdom myself, I am unsure what the changes should be and their implications. I've identified the three place in the Maverick code that need altered. #1 should be fine but I need help on #2 and #3. See below for what I've done so far, with some in-line comments. I gleaned most information from changes.txt in the jdom 1.0 distribution. #1 and #3 look good. See notes by #2. #2 org.infohazard.maverick.util.XML.java public static Map getParams(Element node) { ... if (value == null) { /* OLD CODE: Checks for presence of children if no value present * getChildren() now removed from v1.0 if (paramNode.hasChildren()) value = paramNode.getChildren(); else value = paramNode.getTextTrim(); */ /* NEW CODE: Since this method expects what the name/value pair * param nodes should look like (from this methods javadoc), is there * actually any need to check for child elements? */ value = paramNode.getTextTrim(); } Though the javadocs say the that a param should only look like , there has been support for child elements inside a for a while. Not sure about others, but I know I have used this 'feature' many times in the past. With that being the case I would do something like this for #2. List paramChildren = paramNode.getChildren(); if (!paramChildren.isEmpty()) value = paramChildren; else value = paramNode.getTextTrim(); What are the thoughts of updating the jdom dependency of maverick? If there are no objections I will do the updates and do a 2.2.4 release. -- Mike : mike moulton : meltmedia : 1429 north 1st street : phoenix az 85004 : : [EMAIL PROTECTED] : mmoulton66| aim : 602.340.9440 | ofc : 602.432.2568 | cel : 602.340.1003 | fax : : meltmedia.com --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ [INVALID FOOTER] --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ [INVALID FOOTER]
Re: [Mav-user] Help - falling into 'jar hell' with Mav and JDOM
No objections here. Regards, Eelco What are the thoughts of updating the jdom dependency of maverick? If there are no objections I will do the updates and do a 2.2.4 release. -- Mike --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ [INVALID FOOTER]
Re: [Mav-user] Help - falling into 'jar hell' with Mav and JDOM
Responses inline... I've had a look at changing Maverick to use jdom 1.0, but as I've never used jdom myself, I am unsure what the changes should be and their implications. I've identified the three place in the Maverick code that need altered. #1 should be fine but I need help on #2 and #3. See below for what I've done so far, with some in-line comments. I gleaned most information from changes.txt in the jdom 1.0 distribution. #1 and #3 look good. See notes by #2. #2 org.infohazard.maverick.util.XML.java public static Map getParams(Element node) { ... if (value == null) { /* OLD CODE: Checks for presence of children if no value present * getChildren() now removed from v1.0 if (paramNode.hasChildren()) value = paramNode.getChildren(); else value = paramNode.getTextTrim(); */ /* NEW CODE: Since this method expects what the name/value pair * param nodes should look like (from this methods javadoc), is there * actually any need to check for child elements? */ value = paramNode.getTextTrim(); } Though the javadocs say the that a param should only look like , there has been support for child elements inside a for a while. Not sure about others, but I know I have used this 'feature' many times in the past. With that being the case I would do something like this for #2. List paramChildren = paramNode.getChildren(); if (!paramChildren.isEmpty()) value = paramChildren; else value = paramNode.getTextTrim(); What are the thoughts of updating the jdom dependency of maverick? If there are no objections I will do the updates and do a 2.2.4 release. -- Mike : mike moulton : meltmedia : 1429 north 1st street : phoenix az 85004 : : [EMAIL PROTECTED] : mmoulton66| aim : 602.340.9440 | ofc : 602.432.2568 | cel : 602.340.1003 | fax : : meltmedia.com --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ [INVALID FOOTER]
[Mav-user] Help - falling into 'jar hell' with Mav and JDOM
Hi all, My company currently has a live application running under Maverick. I need to add new functionality using a library that only works with jdom release v1.0. Maverick current uses an earlier version of jdom (beta 7?). With jdom v1.0, there have been API changes, which breaks Maverick. Thus, I'm stuck in 'jar hell'. I've had a look at changing Maverick to use jdom 1.0, but as I've never used jdom myself, I am unsure what the changes should be and their implications. I've identified the three place in the Maverick code that need altered. #1 should be fine but I need help on #2 and #3. See below for what I've done so far, with some in-line comments. I gleaned most information from changes.txt in the jdom 1.0 distribution. I would be very gratefully for some help with this. Thanks David Cuthill #1 org.infohazard.maverick.util.XML.java public class XML { ... static { // OLD CODE - This method now removed from v1.0 and replaced with // a Format.TextMode inner class //outputter.setTextNormalize(true); // NEW CODE outputter.getFormat().setTextMode(Format.TextMode.NORMALIZE); } #2 org.infohazard.maverick.util.XML.java public static Map getParams(Element node) { ... if (value == null) { /* OLD CODE: Checks for presence of children if no value present * getChildren() now removed from v1.0 if (paramNode.hasChildren()) value = paramNode.getChildren(); else value = paramNode.getTextTrim(); */ /* NEW CODE: Since this method expects what the name/value pair * param nodes should look like (from this methods javadoc), is there * actually any need to check for child elements? */ value = paramNode.getTextTrim(); } #3 org.infohazard.maverick.Dispatcher.java -- protected void reloadConfig() throws ConfigException { ... public void go(MaverickContext mctx) throws IOException, ServletException { // OLD CODE: Sets values for indent, newlines & encoding // v1.0 jdom added a Format class to control XMLOutputter behavior. // XMLOutputter outputter = new XMLOutputter(" ", true, "UTF-8"); // NEW CODE: Uses new jdom Format class // I can't see how to explicitly set newlines=true in Format. // Would Format.getRawFormat() or Format.getPrettyFormat() // provide the expected output? XMLOutputter outputter = new XMLOutputter( Format.getCompactFormat().setIndent(" ").setEncoding("UTF-8")); --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ [INVALID FOOTER]