Hi Eric, yeah I think 'we' are happy with that. We will even need to change all the file://conf stuff in other configuration files too.
Bye, Norman 2010/5/9 Eric Charles <[email protected]>: > Hi Norman, > > I will do, but I think this is a partial solution. > Administrator will still have replace in spring-beans.xml file://conf/ with > classpath: > Are we happy with that ? > > Tks, > > Eric > > > On 05/09/2010 03:33 PM, Norman Maurer wrote: >> >> Hi Eric, >> >> I had a quick look and it seems to make sense. could you create a jira >> issue and attach it there... >> >> Thx, >> Norman >> >> 2010/5/9 Eric Charles<[email protected]>: >> >>> >>> Hi Norman, >>> >>> I made a first approach making SpringConfigurationRegistry abstract with >>> 2 >>> implementations (SpringFileConfigurationRegistry and >>> SpringClasspathConfigurationRegistry). >>> I first wanted to use composition, but this would have asked too much >>> refactoring, so I used inheritance. >>> >>> The classpath loader still does not work, as there is at least 3 >>> file://conf >>> definitions in spring-beans.xml. We could ask the administrator to change >>> these, but I find that tedious. >>> This is why I would rather think to a global setting in James.xml or >>> spring-beans.xml that would define the resource loading type. In this >>> case, >>> the attached patch can be forgotten. >>> >>> Tks in advance for your comments on the attached patch (will be removed >>> from >>> the james list, so I copied you). >>> >>> Eric >>> >>> >>> On 05/08/2010 05:28 AM, Norman Maurer wrote: >>> >>> Hi Eric, >>> >>> I like your idea about loading every config from classpath. I think >>> you are right, we should change it. About the proposed fallback >>> strategy I'm not sure. I think we should not try to mix up things to >>> much. Just let use add two different ConfigurationRegistry >>> implementations. One for classpath and one for file, so if someone >>> needs to load things from files he could just swap them out. >>> >>> Bye, >>> Norman >>> >>> >>> 2010/5/5 Eric Charles<[email protected]>: >>> >>>> >>>> Hi, >>>> >>>> To run james in my ide (eclipse), I copied config files from >>>> server/spring-deployment/src/main/config/james to a directory called >>>> conf >>>> a >>>> level upon the root of my project. >>>> The resource loading via the file://conf was ok. >>>> >>>> After, I wanted to load via classpath to have smoother intergration in >>>> my >>>> ide and also thinking to later integration with 3rd parties (simply >>>> using >>>> james jars with embedded resources). >>>> >>>> I changed all needed file://conf/ to classpath: in the xml files >>>> (spring-beans,...). >>>> I also had to change in SpringConfigurationRegistry. >>>> >>> >>> getForComponent line 56 >>> >>>> >>>> from >>>> Resource r =der.getResource("file://conf/" + name + ".xml"); >>>> to >>>> Resource r =der.getResource("classpath:" + name + ".xml"); >>>> >>>> I looked for a system-wide configuration (in James.xml or whatever) that >>>> would allow to define the way resources are loaded (file or classpath) >>>> but >>>> didn't find anything. >>>> >>>> One way to tackle this would be first try on file://conf and rather than >>>> throwing directly the RegistryException, still give a try to classpath. >>>> In case of duplicate config present (file + classpath), the file would >>>> take >>>> the precedence, discarding the classpath. >>>> You could have a default classpath config, and simply override some via >>>> file. >>>> >>>> On pom.xml, we could also add the following (direct ide setup after mvn >>>> eclipse:eclipse). >>>> >>>> <build> >>>> <resources> >>>> <resource> >>>> <directory>src/main/resources</directory> >>>> </resource> >>>> </resources> >>>> .... >>>> >>>> In a first instance, for mvn package, everything could remain as such >>>> (all >>>> files copied to conf). >>>> >>>> Any comment? >>>> Tks, >>>> >>>> Eric >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
