[mule-dev] Re: [mule-issues] [mule-jira] Reopened: (MULE-1311) $MULE_BASE/lib/user folder does not override $MULE_HOME/lib/user

[Andrew Perepelytsya]

I have a solution locally which works cross-platform (tested and confirmed). It's dirty for now, for I have to resolve a module dependency problem. The question is: do we tolerate code duplication for util methods in mule-module-bootstrap? At the moment it's about 3-4 methods already. On the other hand, just blindly adding the bootstrap module dependency to the core creates a cycle and breaks the reactor. We can make bootstrap a special beast (and not inherit the mule-modules pom), so as to break this cycle, but that might require some reshuffling. The XxxUtils in the core could then delegate the duplicated calls to the bootstrap.

Opinions?

Andrew

On 1/13/07, Holger Hoffstaette (JIRA) <no-r...@mulesource.com> wrote:

     [ http://mule.mulesource.org/jira/browse/MULE-1311?page=all ]

Holger Hoffstaette reopened MULE-1311:
--------------------------------------


Test seems platform-dependent; it works on Windows but fails on Unix (Linux), note the file:/ vs. file:// difference in URL handling. Btw File.toURL() is deprecated in JDK5+.

================================================================================
= Testing:  mule base user folder overrides mule home                          =
= (org.mule.modules.boot.DefaultMuleClassPathConfigTestCase )                   =
================================================================================
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.167 sec <<< FAILURE!
mule base user folder overrides mule home ( org.mule.modules.boot.DefaultMuleClassPathConfigTestCase)  Time elapsed: 0.122 sec  <<< FAILURE!
junit.framework.ComparisonFailure: $MULE_BASE/lib/user must come first; expected: 'file:/tmp/mule_test_delete_me/mule_base/lib/user/', got: ' file://tmp/mule_test_delete_me/mule_base/lib/user/', URLs are: [file://tmp/mule_test_delete_me/mule_base/lib/user/ , file://tmp/mule_test_delete_me/mule_home/lib/user/, file://tmp/mule_test_delete_me/mule_home/lib/mule/ , file://tmp/mule_test_delete_me/mule_home/lib/opt/] expected:<......> but was:<.../...>
        at junit.framework.Assert.assertEquals(Assert.java :81)
        at org.mule.modules.boot.DefaultMuleClassPathConfigTestCase.testMuleBaseUserFolderOverridesMuleHome(DefaultMuleClassPathConfigTestCase.java:50)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

[Holger Hoffstätte]

Andrew Perepelytsya wrote:
> I have a solution locally which works cross-platform (tested and
> confirmed).

Please see my attempt attached to the JIRA. I don't think we should have
to add URL prefixes and directory slashes anywhere to get the desired
effect. Having consistent FileUtils.toFile(URL) and FileUtils.toURL(File)
would be good though.

> It's dirty for now, for I have to resolve a module
> dependency problem. The question is: do we tolerate code duplication for
> util methods in mule-module-bootstrap? At the moment it's about 3-4

We have to; even splitting the common classes out will not help because
the bootstrap module may have no other jars yet. Anything else is way too
error-prone.

-h

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email

[Travis Carlson]

> We can make bootstrap a special beast (and not inherit the mule-modules
pom), so as
> to break this cycle, but that might require some reshuffling.

I don't think this solves anything, the problem is not at build-time
(cyclic dependencies in Maven), but at run-time (bootloader not yet having
mule-core in its classpath).

I suppose we could split org.mule.util out into its own module (probably
not a bad idea anyways), and have the bootstrap depend on it
("mule-module-util"), but if the Mule util methods depend on Commons
libraries, we'll still need all that (wrapper + mule-module-util +
commons-libs) as part of the bootloader.

Travis

Opinions?

Andrew

---------------------------------------------------------------------

[Holger Hoffstätte]

Travis Carlson wrote:
> I suppose we could split org.mule.util out into its own module (probably
> not a bad idea anyways), and have the bootstrap depend on it
> ("mule-module-util"), but if the Mule util methods depend on Commons
> libraries, we'll still need all that (wrapper + mule-module-util +
> commons-libs) as part of the bootloader.

That thought crossed my mind as well, but this would only work for those
FooUtils that never, ever, reference a org.mule.* class as argument - i.e.
all generic helpers, otherwise we have another cycle. And as you said it
would not solve the bootstrap problem..

Holger