PDA

View Full Version : Getting Spring.Core 1.0.2 to run in OSX/Mono 1.1.15


osxhacker
05-27-2006, 08:29 PM
Hello All,

First off, let me say I very much like working with Spring both on the .NET and Java platforms. The functionality provided truly makes working in either platform much nicer!

I just did get some hacks in place to successfully get Spring.NET (core) working in OSX (10.4.6) with Mono (1.1.15). Below are the lines changed in order to accomplish this. By no means am I stating that these are "good", "proper", or "correct". :D However, they worked for me and maybe they'll help out a fellow Spring-er.

In Spring.Core/Core/IO/FileSystemResource.cs, line #265:

// Changed from using the Uri property to use "fileHandle.FullName" property
return new FileStream(fileHandle.FullName, FileMode.Open, FileAccess.Read, FileShare.Read);


In Spring.Core/Objects/Factory/Xml/XmlParserRegistry.cs, line #73:

// For whatever reason, registering the validation parser causes Mono to bomb!
// Commenting out this call enables core to work (after a fashion)
// RegisterParser("http://www.springframework.net/validation",
// new ValidationConfigParser(),
// "assembly://Spring.Core/Spring.Validation/spring-validation.xsd");


These are the only changes I can recall making to have Mono on OSX run the Core. Unfortunately I've not gotten the test cases running yet, however these changes do enable a couple of "hello world" type IoC sample projects to work.

Keep up the great work on spring and I'll post more results/mods/experiences on the OSX/Mono platform as they are relevant.

Mark Pollack
05-30-2006, 02:16 PM
Hi "OXHacker"

Thanks loads for helping out with mono support. I set up the mono environment on windows but did not have much luck in the hour or two I spent on it getting unit tests to work - guess I need to figure out my 'dev envirnment' better. The first fix you post looks fine for both MS.NET and mono and the second one we should investigate a little more - but at least we have a good starting point now!

Thanks!
Mark

osxhacker
05-30-2006, 06:39 PM
Hi "OXHacker"

Thanks loads for helping out with mono support. I set up the mono environment on windows but did not have much luck in the hour or two I spent on it getting unit tests to work - guess I need to figure out my 'dev envirnment' better. The first fix you post looks fine for both MS.NET and mono and the second one we should investigate a little more - but at least we have a good starting point now!

Thanks!
Mark

My pleasure Mark. You guys have done a lot of great work on this project, saving me and my team many hours of effort, so this is the least I can do :). Saturday I was able to use a very simple around advice interceptor on my "hello IoC world" sample project, so the Spring.Aop assembly is looking good so far.

If I run into any other problems I'll see if I can narrow down where/what may be the root of them and post here ASAP.

What's causing the test cases to fail to build (using X-develop both 1.2 and 2.0 preview) is, I believe, a mono "resgen" issue. It may be that X-develop is trying to use the mono 1.0 version and should be using resgen2. I'm not sure though. When running nant on the build files, there are properties that I'm not sure what their contents should be. Also, is there a "master level" nant build file that resides where the ".sln" files are? If there should be one there, it seems to be missing from the 1.0.2 distro.

Thanks again and please feel free to let me know if there are more things I can do in the OSX/Mono arena to contribute!

Bruno Baia
05-30-2006, 08:16 PM
In Spring.Core/Core/IO/FileSystemResource.cs, line #265:

// Changed from using the Uri property to use "fileHandle.FullName" property
return new FileStream(fileHandle.FullName, FileMode.Open, FileAccess.Read, FileShare.Read);


Hi,

There was an issue (http://forum.springframework.net/showthread.php?t=472) in FileSystemResource detected after 1.0.2.
I resolved it changing the Uri property like Nat proposed :

public override Uri Uri
{
get { return new UriBuilder("file", null, 0, fileHandle.FullName).Uri; }
}

Maybe we can merge both fix, changing the InputStream property too to use the filehandle as we have it.

Thanks for the feedback about Mono,
Bruno