deprecate/remove or change ServerEnvironment.getModulesDir() which returns a single File representing the AS7 Modules directory path....
3:30 p.m.
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
1:13 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
9:54 a.m.
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.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
- DML
2:16 a.m.
New subject: referencing jars within JBoss Modules
changing the topic ever so slightly.
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.
I'm curious if you want that to apply for users wanting to build against the JBoss AS
runtime jars swell.
i.e. those who want the *exact* possibly bug fix patched jars in the runtime and not
"just" what can
be returned from a maven repo.
Currently in jboss tools we refer to specific locations inside the modules repo to refer
to these jars
and were planning/pondering on starting to read the module metadata to get a more precise
representation
of the actual jars used (and then map the notion of an Eclipse Facet (i.e. jpa facet) to
one or more modules (i.e. javax.persistence.api for API and org.hibernate.* for
implementation)
Is this a dead end road to follow ?
/max
http://about.me/maxandersen
8:53 a.m.
New subject: referencing jars within JBoss Modules
On 08/05/2011 02:16 AM, Max Rydahl Andersen wrote:
changing the topic ever so slightly.
> 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.
I'm curious if you want that to apply for users wanting to build against the JBoss AS
runtime jars swell.
i.e. those who want the *exact* possibly bug fix patched jars in the
runtime and not "just" what can
be returned from a maven repo.
Currently in jboss tools we refer to specific locations inside the modules repo to refer
to these jars
and were planning/pondering on starting to read the module metadata to get a more precise
representation
of the actual jars used (and then map the notion of an Eclipse Facet (i.e. jpa facet) to
one or more modules (i.e. javax.persistence.api for API and org.hibernate.* for
implementation)
Is this a dead end road to follow ?
Hard to tell what this has to do with the original subject, but that's
OK. :)
I think it's very important to always use the same code in the modules
repository as can be found in a public maven repository. This doesn't
necessarily mean the same JARs though. As long as we use the same code
and resources as the original (i.e. fully compilation-compatible) then
we can bundle different (say, signed) JARs without the user having to
really know the difference.
If we patch a project then the proper thing to do is publish the patched
artifact version in our public repository in as similar a way to the
original as possible, *and* make sure that patch (or an equivalent fix)
is pushed upstream; in other words, we should avoid locally patched
versions where possible (this is similar in policy to how Fedora deals
with patches).
All that said... every single JAR does in fact come from Maven so you
can already simply examine the Maven metadata present in each JAR to
know where it "comes from".
Hope I've answered your question.
--
- DML
3:30 p.m.
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
4855
days inactive
4869
days old
5 comments
4 participants
participants (4)
-
David M. Lloyd -
Max Rydahl Andersen -
Scott Marlow -
Thomas Diesler