[jboss-as7-dev] deprecate/remove or change ServerEnvironment.getModulesDir() which returns a single File representing the AS7 Modules directory path....

[Scott Marlow]

I have a side issue attached to this, the ability to test with multiple 
entries on the module path.  If we don't address the ability to have 
multiple entries on the module path, I could do something ugly for my 
testing (like having as/testsuite copy the modules again like they used 
to, in case tests want to modify/add to the modules).

On 07/29/2011 10:54 AM, David M. Lloyd wrote:
> The problem is that the modules directory is a concept which applies to
> the AS, and there may be more than one, or there may be none at all if a
> different module loading scheme is used.
>
> The ServerEnvironment should have no direct knowledge of the module
> system or its filesystem representation.  The only interface with the
> module system should be through the modules API.

Since there were no objections (Brian?) to the assertion that 
ServerEnvironment shouldn't return the module path, I think we should 
move forward on this (probably after the 7.0.1 release).

>
> On 07/29/2011 01:13 AM, Thomas Diesler wrote:
>> Both, the modules and the bundles directory are repositories of
>> artefacts that can be referenced at boot time (or later). We separated
>> the two because we saw dependencies from modules to osgi bundles show
>> up. Also it would be wrong to place a modules.xml (i.e. hard coded
>> dependency definition) alongside a bundle.
>>
>> I suggest to abstract this and introduce a notion on Repository that can
>> be referenced from the ServerEnvironment. The initial implementation
>> could be File based.
>>
>> Repositoy {
>>
>>        URL getModule(String name, String slot);
>> }
>>
>> for example. You could then have a RepositoryModuleLoader. This is just
>> a conceptual idea - please excuse the lack of detail.
>>
>> cheers
>> -thomas
>>
>> On 07/27/2011 10:30 PM, Scott Marlow wrote:
>>> I tried changing the testsuite/pom.xml to allow a hibernate3 test to
>>> supply its own jars in the hibernate3 module (otherwise would be an
>>> empty module), by adding a "testsuite" modules entry to the
>>> module.path.
>>>
>>> It looks like OSGi gets confused by multiple entries in
>>> the module path.
>>>
>>> module.path =
>>> /home/smarlow/work/as7/testsuite/compat/target/jbossas:/home/smarlow/work/as7/testsuite/compat/../../build/target/jboss-as-7.1.0.Alpha1-SNAPSHOT/modules
>>>
>>> server.log http://pastie.org/2278519 that shows what looks like an
>>> OSGI error.
>>>
>>> Earlier today on IRC, we discussed whether the modules directory should
>>> be returned from ServerEnvironment.  The concern being that the boot
>>> module loader might not be filesystem accessible (returning as a File
>>> instance could be wrong).  The other concern is that the module path can
>>> contain multiple paths (separated by native OS file separator).
>>>
>>> The suggestion on IRC was for OSGi to use the server home directory
>>> instead (ServerEnvironment.getHomeDir()).
>>>
>>> How can/should we solve this?  Change the AS7 OSGi integration code to
>>> stop using ServerEnvironment.getModulesDir()?  Can we remove the
>>> ServerEnvironment.getModulesDir() or should we deprecate it?  If we
>>> deprecate it, perhaps it should return File[] to represent the possible
>>> multiple module directories.  Does anyone know of any external caller
>>> into ServerEnvironment.getModulesDir()?
>>>
>>> Scott
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
>