Re: ORO version conflicts

["Daniel F. Savarese" <df...@savarese.org>]

>I am suffering from NoSuchMethodError caused by the method signature of Util.s
>plit() having changed somewhere between versions 2.0.1 and 2.0.7. If this has 
>been discussed elsewhere I can't find it.

The change is listed in the CHANGES file:
Version 2.0.2
  o The org.apache.oro.text.regex.Util.split() method was further 
    generalized to accept a Collection reference argument to store the result.
This corrected the change in 2.0.1:
  o The org.apache.oro.text.regex.Util.split() method was generalized to 
    accept a List reference argument to store the result.

>I am trying to create a product which can be run on most major JSP/Servlet eng
>ines. If I compile against 2.0.7 I get an error from WebLogic 7.0 which has 2.
>0.1 built in. If I compile against 2.0.1 I get an error from JRun 4 which has 
>the newer version built in. Whoever made this change knows they did a bad thin
>g, but is there a workaround which provides some sort of binary compatibility?

The change fixes what should have been done in the 2.0.1 release, when
the new method was added and the Vector returning ones were deprecated.
It was an upwardly source compatible change, so no source that relied
on 2.0.1 would be broken by 2.0.2.  I can't say that was a terrible thing¸
although it was a compromise and regrettable that upward binary
compatibility could not be maintained.  The bad (in the sense you mean),
but necessary, change we made was when we changed the Substitution
interface in 2.0.3.  That sort of change won't happen anymore between
point releases and only happened because the first few 2.0.x releases
were correcting artifacts that should have been in the 2.0 release, but
were missed during the migration from OROMatcher to jakarta-oro.

If not for what I'm going to say in my next paragraph, I think the
workaround would be to use the deprecated Vector split().

However, there is something wrong here.  The fact that WebLogic and JRun
happen to use jakarta-oro somewhere internally does not mean that the
library is there to be used by services hosted inside of the engines
(which I'll generically refer to as servlets).  In other words, jakarta-oro
is not part of their exported APIs.  You should provide your own version
of all libraries your application depends upon and bundle them appropriately
in your WEB-INF/lib or WEB-INF/classes directories.  Don't rely on
libraries that the service container just happens to use.

daniel



---------------------------------------------------------------------
To unsubscribe, e-mail: oro-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-user-help@jakarta.apache.org