11:38 a.m.
The new JBOSS_HOME/server/lib directory pointed to at by the jboss.shared.lib.url property
currently contains the libraries shared by the default and all configurations.
So server/default/lib is now empty and server/all/lib contains only:
avalon-framework.jar
hibernate-jbosscache2.jar
jacorb.jar
jbosscache-core.jar
jbosscache-pojo.jar
jgroups.jar
The new directory is added to the classpath in conf/jboss-service.xml:
<classpath codebase="${jboss.server.lib.url}"
archives="*"/>
<classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
The minimal config remains unchanged.
https://jira.jboss.org/jira/browse/JBAS-6158
You probably need to cleanup your build/output/** directory to pick up the change at your
next svn update.
1:47 p.m.
I'm not the best one to give opinion on that but here it is.
The change will complicate things and confuse users. As well doesn't
seem scalable to me. When we have more server configurations, we'll need
more lib directories (platforms more affected)... The change could break
user utilities that expect the old layout, etc.
IMHO a straightforward approach will be to remove the
JBOSS_HOME/server/*/lib directories altogether and have all libraries in
JBOSS_HOME/lib or another directory. Then appropriate libraries for
every server configuration be selected in a configuration file
(conf/jboss-service.xml?).
Best Regards,
Aleksandar
Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
The new JBOSS_HOME/server/lib directory pointed to at by the
jboss.shared.lib.url property currently contains the libraries shared by
the default and all configurations.
So server/default/lib is now empty and server/all/lib contains only:
avalon-framework.jar
hibernate-jbosscache2.jar
jacorb.jar
jbosscache-core.jar
jbosscache-pojo.jar
jgroups.jar
The new directory is added to the classpath in conf/jboss-service.xml:
<classpath codebase="${jboss.server.lib.url}"
archives="*"/>
<classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
The minimal config remains unchanged.
https://jira.jboss.org/jira/browse/JBAS-6158
You probably need to cleanup your build/output/** directory to pick up
the change at your next svn update.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
2:01 p.m.
On Tue, 2008-11-04 at 14:47 +0200, Aleksandar Kostadinov wrote:
I'm not the best one to give opinion on that but here it is.
The change will complicate things and confuse users. As well doesn't
seem scalable to me. When we have more server configurations,
Its more scalable than having N copies of the jars in the
distribution where N is the number of configurations. :-)
we'll need
more lib directories (platforms more affected)...
This is just a temporary solution until our deployments actually
specify what they use (classloading dependencies).
Once that is done we would only need one
repository/lib folder which would be loaded from as required
and the current server/[conf]/lib folder for people that
are too lazy to specify their dependencies. :-)
The change could break
user utilities that expect the old layout, etc.
Its JBoss5 so although change for change sake is not good,
something that has benefit (smaller distribution size)
is something that can change in a major release.
IMHO a straightforward approach will be to remove the
JBOSS_HOME/server/*/lib directories altogether and have all libraries in
JBOSS_HOME/lib or another directory. Then appropriate libraries for
every server configuration be selected in a configuration file
(conf/jboss-service.xml?).
That makes a user's life harder. They have to modify the
configuration file to add shared jars (e.g. a jdbc driver)
whereas before they could just drop it in server/[conf]/lib
without further configuration steps.
I wouldn't have a problem with having all our jars
in the shared lib folder and explicitly list them
in jboss-service.xml according to what the configuration
uses.
i.e. server/all/lib would be empty but
server/all/conf/jboss-service.xml would list more jars
than server/default/lib
This would also mean that the minimal config is smaller,
nothin in server/minimal/lib
Best Regards,
Aleksandar
Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
> The new JBOSS_HOME/server/lib directory pointed to at by the
> jboss.shared.lib.url property currently contains the libraries shared by
> the default and all configurations.
>
> So server/default/lib is now empty and server/all/lib contains only:
>
> avalon-framework.jar
> hibernate-jbosscache2.jar
> jacorb.jar
> jbosscache-core.jar
> jbosscache-pojo.jar
> jgroups.jar
>
> The new directory is added to the classpath in conf/jboss-service.xml:
>
> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
> <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
>
> The minimal config remains unchanged.
>
> https://jira.jboss.org/jira/browse/JBAS-6158
>
> You probably need to cleanup your build/output/** directory to pick up
> the change at your next svn update.
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
3:11 p.m.
Adrian Brock wrote, On 11/04/2008 03:01 PM (EEST):
On Tue, 2008-11-04 at 14:47 +0200, Aleksandar Kostadinov wrote:
> I'm not the best one to give opinion on that but here it is.
>
> The change will complicate things and confuse users. As well doesn't
> seem scalable to me. When we have more server configurations,
Its more scalable than having N copies of the jars in the
distribution where N is the number of configurations. :-)
Yeah, but what I suggested is even better 8-)
> we'll need
> more lib directories (platforms more affected)...
This is just a temporary solution until our deployments actually
specify what they use (classloading dependencies).
Once that is done we would only need one
repository/lib folder which would be loaded from as required
and the current server/[conf]/lib folder for people that
are too lazy to specify their dependencies. :-)
A temporary solution that we would need to carry for 5 years+ if not
fixed for EAP 5. I *feel* that at least we in QE will have troubles with
our scripts with changing layouts.
> The change could break
> user utilities that expect the old layout, etc.
Its JBoss5 so although change for change sake is not good,
something that has benefit (smaller distribution size)
is something that can change in a major release.
> IMHO a straightforward approach will be to remove the
> JBOSS_HOME/server/*/lib directories altogether and have all libraries in
> JBOSS_HOME/lib or another directory. Then appropriate libraries for
> every server configuration be selected in a configuration file
> (conf/jboss-service.xml?).
>
That makes a user's life harder. They have to modify the
configuration file to add shared jars (e.g. a jdbc driver)
whereas before they could just drop it in server/[conf]/lib
without further configuration steps.
If you leave the server/[conf]/lib for user libs and use configuration
file for our shared libs then I see no drawbacks for the users.
I wouldn't have a problem with having all our jars
in the shared lib folder and explicitly list them
in jboss-service.xml according to what the configuration
uses.
i.e. server/all/lib would be empty but
server/all/conf/jboss-service.xml would list more jars
than server/default/lib
This would also mean that the minimal config is smaller,
nothin in server/minimal/lib
> Best Regards,
> Aleksandar
>
> Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
>> The new JBOSS_HOME/server/lib directory pointed to at by the
>> jboss.shared.lib.url property currently contains the libraries shared by
>> the default and all configurations.
>>
>> So server/default/lib is now empty and server/all/lib contains only:
>>
>> avalon-framework.jar
>> hibernate-jbosscache2.jar
>> jacorb.jar
>> jbosscache-core.jar
>> jbosscache-pojo.jar
>> jgroups.jar
>>
>> The new directory is added to the classpath in conf/jboss-service.xml:
>>
>> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
>> <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
>>
>> The minimal config remains unchanged.
>>
>> https://jira.jboss.org/jira/browse/JBAS-6158
>>
>> You probably need to cleanup your build/output/** directory to pick up
>> the change at your next svn update.
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
5:23 p.m.
Please do not locate it at server/lib. As was mentioned before, directories under
'server' have been configurations since forever(?). If you really need a common
location, call it common/lib.
Peter Johnson
-----Original Message-----
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Aleksandar Kostadinov
Sent: Tuesday, November 04, 2008 6:11 AM
To: JBoss.org development list
Subject: Re: [jboss-dev] new shared JBOSS_HOME/server/lib directory
Adrian Brock wrote, On 11/04/2008 03:01 PM (EEST):
On Tue, 2008-11-04 at 14:47 +0200, Aleksandar Kostadinov wrote:
> I'm not the best one to give opinion on that but here it is.
>
> The change will complicate things and confuse users. As well doesn't
> seem scalable to me. When we have more server configurations,
Its more scalable than having N copies of the jars in the
distribution where N is the number of configurations. :-)
Yeah, but what I suggested is even better 8-)
> we'll need
> more lib directories (platforms more affected)...
This is just a temporary solution until our deployments actually
specify what they use (classloading dependencies).
Once that is done we would only need one
repository/lib folder which would be loaded from as required
and the current server/[conf]/lib folder for people that
are too lazy to specify their dependencies. :-)
A temporary solution that we would need to carry for 5 years+ if not
fixed for EAP 5. I *feel* that at least we in QE will have troubles with
our scripts with changing layouts.
> The change could break
> user utilities that expect the old layout, etc.
Its JBoss5 so although change for change sake is not good,
something that has benefit (smaller distribution size)
is something that can change in a major release.
> IMHO a straightforward approach will be to remove the
> JBOSS_HOME/server/*/lib directories altogether and have all libraries in
> JBOSS_HOME/lib or another directory. Then appropriate libraries for
> every server configuration be selected in a configuration file
> (conf/jboss-service.xml?).
>
That makes a user's life harder. They have to modify the
configuration file to add shared jars (e.g. a jdbc driver)
whereas before they could just drop it in server/[conf]/lib
without further configuration steps.
If you leave the server/[conf]/lib for user libs and use configuration
file for our shared libs then I see no drawbacks for the users.
I wouldn't have a problem with having all our jars
in the shared lib folder and explicitly list them
in jboss-service.xml according to what the configuration
uses.
i.e. server/all/lib would be empty but
server/all/conf/jboss-service.xml would list more jars
than server/default/lib
This would also mean that the minimal config is smaller,
nothin in server/minimal/lib
> Best Regards,
> Aleksandar
>
> Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
>> The new JBOSS_HOME/server/lib directory pointed to at by the
>> jboss.shared.lib.url property currently contains the libraries shared by
>> the default and all configurations.
>>
>> So server/default/lib is now empty and server/all/lib contains only:
>>
>> avalon-framework.jar
>> hibernate-jbosscache2.jar
>> jacorb.jar
>> jbosscache-core.jar
>> jbosscache-pojo.jar
>> jgroups.jar
>>
>> The new directory is added to the classpath in conf/jboss-service.xml:
>>
>> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
>> <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
>>
>> The minimal config remains unchanged.
>>
>> https://jira.jboss.org/jira/browse/JBAS-6158
>>
>> You probably need to cleanup your build/output/** directory to pick up
>> the change at your next svn update.
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
5:04 p.m.
On Tue, 2008-11-04 at 10:23 -0600, Johnson, Peter wrote:
Please do not locate it at server/lib. As was mentioned before,
directories under 'server' have been configurations since forever(?). If you
really need a common location, call it common/lib.
Good point. Somebody might have a configuration called
"lib", i.e.
./run.sh -c lib
Although its very much an edge case it would be much cleaner
to have these common jars away from the server folder.
Peter Johnson
-----Original Message-----
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Aleksandar Kostadinov
Sent: Tuesday, November 04, 2008 6:11 AM
To: JBoss.org development list
Subject: Re: [jboss-dev] new shared JBOSS_HOME/server/lib directory
Adrian Brock wrote, On 11/04/2008 03:01 PM (EEST):
> On Tue, 2008-11-04 at 14:47 +0200, Aleksandar Kostadinov wrote:
>> I'm not the best one to give opinion on that but here it is.
>>
>> The change will complicate things and confuse users. As well doesn't
>> seem scalable to me. When we have more server configurations,
>
> Its more scalable than having N copies of the jars in the
> distribution where N is the number of configurations. :-)
Yeah, but what I suggested is even better 8-)
>> we'll need
>> more lib directories (platforms more affected)...
>
> This is just a temporary solution until our deployments actually
> specify what they use (classloading dependencies).
> Once that is done we would only need one
> repository/lib folder which would be loaded from as required
> and the current server/[conf]/lib folder for people that
> are too lazy to specify their dependencies. :-)
A temporary solution that we would need to carry for 5 years+ if not
fixed for EAP 5. I *feel* that at least we in QE will have troubles with
our scripts with changing layouts.
>> The change could break
>> user utilities that expect the old layout, etc.
>
> Its JBoss5 so although change for change sake is not good,
> something that has benefit (smaller distribution size)
> is something that can change in a major release.
>
>> IMHO a straightforward approach will be to remove the
>> JBOSS_HOME/server/*/lib directories altogether and have all libraries in
>> JBOSS_HOME/lib or another directory. Then appropriate libraries for
>> every server configuration be selected in a configuration file
>> (conf/jboss-service.xml?).
>>
>
> That makes a user's life harder. They have to modify the
> configuration file to add shared jars (e.g. a jdbc driver)
> whereas before they could just drop it in server/[conf]/lib
> without further configuration steps.
If you leave the server/[conf]/lib for user libs and use configuration
file for our shared libs then I see no drawbacks for the users.
> I wouldn't have a problem with having all our jars
> in the shared lib folder and explicitly list them
> in jboss-service.xml according to what the configuration
> uses.
> i.e. server/all/lib would be empty but
> server/all/conf/jboss-service.xml would list more jars
> than server/default/lib
>
> This would also mean that the minimal config is smaller,
> nothin in server/minimal/lib
>
>> Best Regards,
>> Aleksandar
>>
>> Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
>>> The new JBOSS_HOME/server/lib directory pointed to at by the
>>> jboss.shared.lib.url property currently contains the libraries shared by
>>> the default and all configurations.
>>>
>>> So server/default/lib is now empty and server/all/lib contains only:
>>>
>>> avalon-framework.jar
>>> hibernate-jbosscache2.jar
>>> jacorb.jar
>>> jbosscache-core.jar
>>> jbosscache-pojo.jar
>>> jgroups.jar
>>>
>>> The new directory is added to the classpath in conf/jboss-service.xml:
>>>
>>> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
>>> <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
>>>
>>> The minimal config remains unchanged.
>>>
>>> https://jira.jboss.org/jira/browse/JBAS-6158
>>>
>>> You probably need to cleanup your build/output/** directory to pick up
>>> the change at your next svn update.
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
5:36 p.m.
My initial proposal was for JBOSS_HOME/shared/lib
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182964
Johnson, Peter wrote:
Please do not locate it at server/lib. As was mentioned before,
directories under 'server' have been configurations since forever(?). If you
really need a common location, call it common/lib.
Peter Johnson
-----Original Message-----
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Aleksandar Kostadinov
Sent: Tuesday, November 04, 2008 6:11 AM
To: JBoss.org development list
Subject: Re: [jboss-dev] new shared JBOSS_HOME/server/lib directory
Adrian Brock wrote, On 11/04/2008 03:01 PM (EEST):
> On Tue, 2008-11-04 at 14:47 +0200, Aleksandar Kostadinov wrote:
>> I'm not the best one to give opinion on that but here it is.
>>
>> The change will complicate things and confuse users. As well doesn't
>> seem scalable to me. When we have more server configurations,
> Its more scalable than having N copies of the jars in the
> distribution where N is the number of configurations. :-)
Yeah, but what I suggested is even better 8-)
>> we'll need
>> more lib directories (platforms more affected)...
> This is just a temporary solution until our deployments actually
> specify what they use (classloading dependencies).
> Once that is done we would only need one
> repository/lib folder which would be loaded from as required
> and the current server/[conf]/lib folder for people that
> are too lazy to specify their dependencies. :-)
A temporary solution that we would need to carry for 5 years+ if not
fixed for EAP 5. I *feel* that at least we in QE will have troubles with
our scripts with changing layouts.
>> The change could break
>> user utilities that expect the old layout, etc.
> Its JBoss5 so although change for change sake is not good,
> something that has benefit (smaller distribution size)
> is something that can change in a major release.
>
>> IMHO a straightforward approach will be to remove the
>> JBOSS_HOME/server/*/lib directories altogether and have all libraries in
>> JBOSS_HOME/lib or another directory. Then appropriate libraries for
>> every server configuration be selected in a configuration file
>> (conf/jboss-service.xml?).
>>
> That makes a user's life harder. They have to modify the
> configuration file to add shared jars (e.g. a jdbc driver)
> whereas before they could just drop it in server/[conf]/lib
> without further configuration steps.
If you leave the server/[conf]/lib for user libs and use configuration
file for our shared libs then I see no drawbacks for the users.
> I wouldn't have a problem with having all our jars
> in the shared lib folder and explicitly list them
> in jboss-service.xml according to what the configuration
> uses.
> i.e. server/all/lib would be empty but
> server/all/conf/jboss-service.xml would list more jars
> than server/default/lib
>
> This would also mean that the minimal config is smaller,
> nothin in server/minimal/lib
>
>> Best Regards,
>> Aleksandar
>>
>> Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
>>> The new JBOSS_HOME/server/lib directory pointed to at by the
>>> jboss.shared.lib.url property currently contains the libraries shared by
>>> the default and all configurations.
>>>
>>> So server/default/lib is now empty and server/all/lib contains only:
>>>
>>> avalon-framework.jar
>>> hibernate-jbosscache2.jar
>>> jacorb.jar
>>> jbosscache-core.jar
>>> jbosscache-pojo.jar
>>> jgroups.jar
>>>
>>> The new directory is added to the classpath in conf/jboss-service.xml:
>>>
>>> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
>>> <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
>>>
>>> The minimal config remains unchanged.
>>>
>>> https://jira.jboss.org/jira/browse/JBAS-6158
>>>
>>> You probably need to cleanup your build/output/** directory to pick up
>>> the change at your next svn update.
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
3:11 p.m.
The primary motivation for the change at this point was to save space (17.7Mb) from the
distro because we need to add a new "standard" tck config. (Or change the
default to conform
to that).
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182964
The only "confusing" thing for me is that directories under server have always
represented
configurations, but then again the name 'lib' should make it obvious.
Beyond that it doesn't look too bad and things should work as before and even the
testsuite
looks happy).
User scripts that copy files around to create custom configs would need to be updated,
sure.
As Adrian says, things will change again in a future release.
Adrian Brock wrote:
On Tue, 2008-11-04 at 14:47 +0200, Aleksandar Kostadinov wrote:
> I'm not the best one to give opinion on that but here it is.
>
> The change will complicate things and confuse users. As well doesn't
> seem scalable to me. When we have more server configurations,
Its more scalable than having N copies of the jars in the
distribution where N is the number of configurations. :-)
> we'll need
> more lib directories (platforms more affected)...
This is just a temporary solution until our deployments actually
specify what they use (classloading dependencies).
Once that is done we would only need one
repository/lib folder which would be loaded from as required
and the current server/[conf]/lib folder for people that
are too lazy to specify their dependencies. :-)
> The change could break
> user utilities that expect the old layout, etc.
Its JBoss5 so although change for change sake is not good,
something that has benefit (smaller distribution size)
is something that can change in a major release.
> IMHO a straightforward approach will be to remove the
> JBOSS_HOME/server/*/lib directories altogether and have all libraries in
> JBOSS_HOME/lib or another directory. Then appropriate libraries for
> every server configuration be selected in a configuration file
> (conf/jboss-service.xml?).
>
That makes a user's life harder. They have to modify the
configuration file to add shared jars (e.g. a jdbc driver)
whereas before they could just drop it in server/[conf]/lib
without further configuration steps.
I wouldn't have a problem with having all our jars
in the shared lib folder and explicitly list them
in jboss-service.xml according to what the configuration
uses.
i.e. server/all/lib would be empty but
server/all/conf/jboss-service.xml would list more jars
than server/default/lib
This would also mean that the minimal config is smaller,
nothin in server/minimal/lib
> Best Regards,
> Aleksandar
>
> Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
>> The new JBOSS_HOME/server/lib directory pointed to at by the
>> jboss.shared.lib.url property currently contains the libraries shared by
>> the default and all configurations.
>>
>> So server/default/lib is now empty and server/all/lib contains only:
>>
>> avalon-framework.jar
>> hibernate-jbosscache2.jar
>> jacorb.jar
>> jbosscache-core.jar
>> jbosscache-pojo.jar
>> jgroups.jar
>>
>> The new directory is added to the classpath in conf/jboss-service.xml:
>>
>> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
>> <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
>>
>> The minimal config remains unchanged.
>>
>> https://jira.jboss.org/jira/browse/JBAS-6158
>>
>> You probably need to cleanup your build/output/** directory to pick up
>> the change at your next svn update.
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
2:02 p.m.
Another option would be to have a "*.lnk" (or whatever *.alias)
extension which would just contains a URL to the new target (absolute or
relative). That way we get the best of both world.
i.e. default/lib/ would contain things such as:
avalon-framework.jar.lnk
hibernate-jbosscache2.jar.lnk
jacorb.jar.lnk
jbosscache-core.jar-lnk
jbosscache-pojo.jar.lnk
jgroups.jar.lnk
and this new referral deployer would simply dynamically add to the
deployment list the target JAR minus the ".lnk" extension.
Thoughts?
-----Original Message-----
From: jboss-development-bounces(a)lists.jboss.org [mailto:jboss-
development-bounces(a)lists.jboss.org] On Behalf Of Aleksandar Kostadinov
Sent: mardi, 4 novembre 2008 13:48
To: JBoss.org development list
Subject: Re: [jboss-dev] new shared JBOSS_HOME/server/lib directory
I'm not the best one to give opinion on that but here it is.
The change will complicate things and confuse users. As well doesn't
seem scalable to me. When we have more server configurations, we'll
need
more lib directories (platforms more affected)... The change could
break
user utilities that expect the old layout, etc.
IMHO a straightforward approach will be to remove the
JBOSS_HOME/server/*/lib directories altogether and have all libraries
in
JBOSS_HOME/lib or another directory. Then appropriate libraries for
every server configuration be selected in a configuration file
(conf/jboss-service.xml?).
Best Regards,
Aleksandar
Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
> The new JBOSS_HOME/server/lib directory pointed to at by the
> jboss.shared.lib.url property currently contains the libraries shared
by
> the default and all configurations.
>
> So server/default/lib is now empty and server/all/lib contains only:
>
> avalon-framework.jar
> hibernate-jbosscache2.jar
> jacorb.jar
> jbosscache-core.jar
> jbosscache-pojo.jar
> jgroups.jar
>
> The new directory is added to the classpath in conf/jboss-
service.xml:
>
> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
> <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
>
> The minimal config remains unchanged.
>
> https://jira.jboss.org/jira/browse/JBAS-6158
>
> You probably need to cleanup your build/output/** directory to pick
up
> the change at your next svn update.
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
2:02 p.m.
Scott Stark:
"Every problem can be resolved by an extra indirection"
Adrian Brock:
"Every indirection reduces understanding and increases errors" :-)
On Tue, 2008-11-04 at 14:02 +0100, Sacha Labourey wrote:
Another option would be to have a "*.lnk" (or whatever
*.alias)
extension which would just contains a URL to the new target (absolute or
relative). That way we get the best of both world.
i.e. default/lib/ would contain things such as:
avalon-framework.jar.lnk
hibernate-jbosscache2.jar.lnk
jacorb.jar.lnk
jbosscache-core.jar-lnk
jbosscache-pojo.jar.lnk
jgroups.jar.lnk
How is this different from listing the jars in jboss-service.xml?
and this new referral deployer would simply dynamically add to the
deployment list the target JAR minus the ".lnk" extension.
Thoughts?
> -----Original Message-----
> From: jboss-development-bounces(a)lists.jboss.org [mailto:jboss-
> development-bounces(a)lists.jboss.org] On Behalf Of Aleksandar Kostadinov
> Sent: mardi, 4 novembre 2008 13:48
> To: JBoss.org development list
> Subject: Re: [jboss-dev] new shared JBOSS_HOME/server/lib directory
>
> I'm not the best one to give opinion on that but here it is.
>
> The change will complicate things and confuse users. As well doesn't
> seem scalable to me. When we have more server configurations, we'll
> need
> more lib directories (platforms more affected)... The change could
> break
> user utilities that expect the old layout, etc.
>
> IMHO a straightforward approach will be to remove the
> JBOSS_HOME/server/*/lib directories altogether and have all libraries
> in
> JBOSS_HOME/lib or another directory. Then appropriate libraries for
> every server configuration be selected in a configuration file
> (conf/jboss-service.xml?).
>
> Best Regards,
> Aleksandar
>
> Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
> > The new JBOSS_HOME/server/lib directory pointed to at by the
> > jboss.shared.lib.url property currently contains the libraries shared
> by
> > the default and all configurations.
> >
> > So server/default/lib is now empty and server/all/lib contains only:
> >
> > avalon-framework.jar
> > hibernate-jbosscache2.jar
> > jacorb.jar
> > jbosscache-core.jar
> > jbosscache-pojo.jar
> > jgroups.jar
> >
> > The new directory is added to the classpath in conf/jboss-
> service.xml:
> >
> > <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
> > <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
> >
> > The minimal config remains unchanged.
> >
> > https://jira.jboss.org/jira/browse/JBAS-6158
> >
> > You probably need to cleanup your build/output/** directory to pick
> up
> > the change at your next svn update.
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
2:20 p.m.
I think we currently need a simple out-of-the-box solution,
just something that won't bloat our distro too much.
Scott's/Dimitris's shared dir does just that.
What you're suggesting Sacha is something OBR (OSGi Bundle Repository)
already does.
.lnk is actually 'equivalent' to a requirement in OSGi import
or our ClassLoadingMetaData's module requirement.
Then it's just a matter of how we implement this requirement/jar pulling .
e.g. where do we put this dependency jars, how much pulling we allow, etc.
Sacha Labourey wrote:
Another option would be to have a "*.lnk" (or whatever
*.alias)
extension which would just contains a URL to the new target (absolute or
relative). That way we get the best of both world.
i.e. default/lib/ would contain things such as:
avalon-framework.jar.lnk
hibernate-jbosscache2.jar.lnk
jacorb.jar.lnk
jbosscache-core.jar-lnk
jbosscache-pojo.jar.lnk
jgroups.jar.lnk
and this new referral deployer would simply dynamically add to the
deployment list the target JAR minus the ".lnk" extension.
Thoughts?
> -----Original Message-----
> From: jboss-development-bounces(a)lists.jboss.org [mailto:jboss-
> development-bounces(a)lists.jboss.org] On Behalf Of Aleksandar Kostadinov
> Sent: mardi, 4 novembre 2008 13:48
> To: JBoss.org development list
> Subject: Re: [jboss-dev] new shared JBOSS_HOME/server/lib directory
>
> I'm not the best one to give opinion on that but here it is.
>
> The change will complicate things and confuse users. As well doesn't
> seem scalable to me. When we have more server configurations, we'll
> need
> more lib directories (platforms more affected)... The change could
> break
> user utilities that expect the old layout, etc.
>
> IMHO a straightforward approach will be to remove the
> JBOSS_HOME/server/*/lib directories altogether and have all libraries
> in
> JBOSS_HOME/lib or another directory. Then appropriate libraries for
> every server configuration be selected in a configuration file
> (conf/jboss-service.xml?).
>
> Best Regards,
> Aleksandar
>
> Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
>> The new JBOSS_HOME/server/lib directory pointed to at by the
>> jboss.shared.lib.url property currently contains the libraries shared
> by
>> the default and all configurations.
>>
>> So server/default/lib is now empty and server/all/lib contains only:
>>
>> avalon-framework.jar
>> hibernate-jbosscache2.jar
>> jacorb.jar
>> jbosscache-core.jar
>> jbosscache-pojo.jar
>> jgroups.jar
>>
>> The new directory is added to the classpath in conf/jboss-
> service.xml:
>> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
>> <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
>>
>> The minimal config remains unchanged.
>>
>> https://jira.jboss.org/jira/browse/JBAS-6158
>>
>> You probably need to cleanup your build/output/** directory to pick
> up
>> the change at your next svn update.
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
3:26 p.m.
JBOSS_HOME/lib is our bootstrap directory so we wouldn't add shared libs there. And
any new
directory we introduce will break scripts anyway.
The only point of discussion is whether to put all libs in server/lib and reference them
explicitly, or put only the shared ones and reference them implicitly.
The down side for referencing explicitly the chosen libs is that it is harder to maintain,
since whenever a lib is added you'd have to update all affected configurations.
The up side is that you have a single lib dir for server libs.
Aleksandar Kostadinov wrote:
I'm not the best one to give opinion on that but here it is.
The change will complicate things and confuse users. As well doesn't
seem scalable to me. When we have more server configurations, we'll need
more lib directories (platforms more affected)... The change could break
user utilities that expect the old layout, etc.
IMHO a straightforward approach will be to remove the
JBOSS_HOME/server/*/lib directories altogether and have all libraries in
JBOSS_HOME/lib or another directory. Then appropriate libraries for
every server configuration be selected in a configuration file
(conf/jboss-service.xml?).
Best Regards,
Aleksandar
Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
> The new JBOSS_HOME/server/lib directory pointed to at by the
> jboss.shared.lib.url property currently contains the libraries shared
> by the default and all configurations.
>
> So server/default/lib is now empty and server/all/lib contains only:
>
> avalon-framework.jar
> hibernate-jbosscache2.jar
> jacorb.jar
> jbosscache-core.jar
> jbosscache-pojo.jar
> jgroups.jar
>
> The new directory is added to the classpath in conf/jboss-service.xml:
>
> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
> <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
>
> The minimal config remains unchanged.
>
> https://jira.jboss.org/jira/browse/JBAS-6158
>
> You probably need to cleanup your build/output/** directory to pick up
> the change at your next svn update.
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
4:43 p.m.
If that matters here is my vote:
"libs in server/lib and reference them explicitly"
This way all servers will be consistent. And there will be low overhead
for adding configurations.
If possible use some dir outside servers.
Regards
Dimitris Andreadis wrote, On 11/04/2008 04:26 PM (EEST):
JBOSS_HOME/lib is our bootstrap directory so we wouldn't add
shared libs
there. And any new directory we introduce will break scripts anyway.
The only point of discussion is whether to put all libs in server/lib
and reference them explicitly, or put only the shared ones and reference
them implicitly.
The down side for referencing explicitly the chosen libs is that it is
harder to maintain, since whenever a lib is added you'd have to update
all affected configurations.
The up side is that you have a single lib dir for server libs.
Aleksandar Kostadinov wrote:
> I'm not the best one to give opinion on that but here it is.
>
> The change will complicate things and confuse users. As well doesn't
> seem scalable to me. When we have more server configurations, we'll
> need more lib directories (platforms more affected)... The change
> could break user utilities that expect the old layout, etc.
>
> IMHO a straightforward approach will be to remove the
> JBOSS_HOME/server/*/lib directories altogether and have all libraries
> in JBOSS_HOME/lib or another directory. Then appropriate libraries for
> every server configuration be selected in a configuration file
> (conf/jboss-service.xml?).
>
> Best Regards,
> Aleksandar
>
> Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
>> The new JBOSS_HOME/server/lib directory pointed to at by the
>> jboss.shared.lib.url property currently contains the libraries shared
>> by the default and all configurations.
>>
>> So server/default/lib is now empty and server/all/lib contains only:
>>
>> avalon-framework.jar
>> hibernate-jbosscache2.jar
>> jacorb.jar
>> jbosscache-core.jar
>> jbosscache-pojo.jar
>> jgroups.jar
>>
>> The new directory is added to the classpath in conf/jboss-service.xml:
>>
>> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
>> <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
>>
>> The minimal config remains unchanged.
>>
>> https://jira.jboss.org/jira/browse/JBAS-6158
>>
>> You probably need to cleanup your build/output/** directory to pick
>> up the change at your next svn update.
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
4:32 p.m.
Voting is irrelevant.
Reasoned arguments are what counts in software design.
e.g. It only takes one person to give one example that
shows that something is fundamentally flawed
despite everybody else voting for it. :-)
For example, the problem with your "everything in server/lib"
would be that it is very difficult for somebody to have
different jboss configurations in the same installation
for developing different versions of their applications.
i.e. where the shared jars need to change version
I agree with it for our jars since there's no reason
for two different versions of the shared jboss jars
in the same jboss installation.
Versioning is something that the "OBR" solution would cover
when it is completed and would remove my criticism.
On Tue, 2008-11-04 at 17:43 +0200, Aleksandar Kostadinov wrote:
If that matters here is my vote:
"libs in server/lib and reference them explicitly"
This way all servers will be consistent. And there will be low overhead
for adding configurations.
If possible use some dir outside servers.
Regards
Dimitris Andreadis wrote, On 11/04/2008 04:26 PM (EEST):
> JBOSS_HOME/lib is our bootstrap directory so we wouldn't add shared libs
> there. And any new directory we introduce will break scripts anyway.
>
> The only point of discussion is whether to put all libs in server/lib
> and reference them explicitly, or put only the shared ones and reference
> them implicitly.
>
> The down side for referencing explicitly the chosen libs is that it is
> harder to maintain, since whenever a lib is added you'd have to update
> all affected configurations.
>
> The up side is that you have a single lib dir for server libs.
>
> Aleksandar Kostadinov wrote:
>> I'm not the best one to give opinion on that but here it is.
>>
>> The change will complicate things and confuse users. As well doesn't
>> seem scalable to me. When we have more server configurations, we'll
>> need more lib directories (platforms more affected)... The change
>> could break user utilities that expect the old layout, etc.
>>
>> IMHO a straightforward approach will be to remove the
>> JBOSS_HOME/server/*/lib directories altogether and have all libraries
>> in JBOSS_HOME/lib or another directory. Then appropriate libraries for
>> every server configuration be selected in a configuration file
>> (conf/jboss-service.xml?).
>>
>> Best Regards,
>> Aleksandar
>>
>> Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
>>> The new JBOSS_HOME/server/lib directory pointed to at by the
>>> jboss.shared.lib.url property currently contains the libraries shared
>>> by the default and all configurations.
>>>
>>> So server/default/lib is now empty and server/all/lib contains only:
>>>
>>> avalon-framework.jar
>>> hibernate-jbosscache2.jar
>>> jacorb.jar
>>> jbosscache-core.jar
>>> jbosscache-pojo.jar
>>> jgroups.jar
>>>
>>> The new directory is added to the classpath in conf/jboss-service.xml:
>>>
>>> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
>>> <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
>>>
>>> The minimal config remains unchanged.
>>>
>>> https://jira.jboss.org/jira/browse/JBAS-6158
>>>
>>> You probably need to cleanup your build/output/** directory to pick
>>> up the change at your next svn update.
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
5:35 p.m.
Adrian Brock wrote, On 11/04/2008 05:32 PM (EEST):
Voting is irrelevant.
Reasoned arguments are what counts in software design.
e.g. It only takes one person to give one example that
shows that something is fundamentally flawed
despite everybody else voting for it. :-)
So you're saying the approach I suggest is *fundamentally* flawed? See
below why I don't agree. I just opt for a better temporary solution so
we don't have to deal with the current for a long time. If too hard then
I'm ok with that.
Let me summarize what I don't like in current server/lib approach and I
hope that to be my last mail.
1. repurposing servers directory (I think better would be
JBOSS_HOME/shared or something)
2. will possibly be hardly reusable for additional server configurations
(imagine if we want one less lib in the configuration) + leads again to
duplication of libs in the distribution (although much less).
3. one can't easily change a bundled library only in one configuration
for some test purposes (imagine security update testing)
For example, the problem with your "everything in
server/lib"
would be that it is very difficult for somebody to have
different jboss configurations in the same installation
for developing different versions of their applications.
i.e. where the shared jars need to change version
Actually I just said (or wanted to say) that server/*/lib can be
deleted, not that it should. See my latter emails. I agree these should
stay to keep user libs if users want to use them. All arguments against
my suggestion I saw were against that small detail of removing server/*/lib.
Does that address your concern?
I agree with it for our jars since there's no reason
for two different versions of the shared jboss jars
in the same jboss installation.
So you're sold on the idea? :)
Versioning is something that the "OBR" solution would
cover
when it is completed and would remove my criticism.
On Tue, 2008-11-04 at 17:43 +0200, Aleksandar Kostadinov wrote:
> If that matters here is my vote:
>
> "libs in server/lib and reference them explicitly"
>
> This way all servers will be consistent. And there will be low overhead
> for adding configurations.
>
> If possible use some dir outside servers.
>
> Regards
>
> Dimitris Andreadis wrote, On 11/04/2008 04:26 PM (EEST):
>> JBOSS_HOME/lib is our bootstrap directory so we wouldn't add shared libs
>> there. And any new directory we introduce will break scripts anyway.
>>
>> The only point of discussion is whether to put all libs in server/lib
>> and reference them explicitly, or put only the shared ones and reference
>> them implicitly.
>>
>> The down side for referencing explicitly the chosen libs is that it is
>> harder to maintain, since whenever a lib is added you'd have to update
>> all affected configurations.
>>
>> The up side is that you have a single lib dir for server libs.
>>
>> Aleksandar Kostadinov wrote:
>>> I'm not the best one to give opinion on that but here it is.
>>>
>>> The change will complicate things and confuse users. As well doesn't
>>> seem scalable to me. When we have more server configurations, we'll
>>> need more lib directories (platforms more affected)... The change
>>> could break user utilities that expect the old layout, etc.
>>>
>>> IMHO a straightforward approach will be to remove the
>>> JBOSS_HOME/server/*/lib directories altogether and have all libraries
>>> in JBOSS_HOME/lib or another directory. Then appropriate libraries for
>>> every server configuration be selected in a configuration file
>>> (conf/jboss-service.xml?).
>>>
>>> Best Regards,
>>> Aleksandar
>>>
>>> Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
>>>> The new JBOSS_HOME/server/lib directory pointed to at by the
>>>> jboss.shared.lib.url property currently contains the libraries shared
>>>> by the default and all configurations.
>>>>
>>>> So server/default/lib is now empty and server/all/lib contains only:
>>>>
>>>> avalon-framework.jar
>>>> hibernate-jbosscache2.jar
>>>> jacorb.jar
>>>> jbosscache-core.jar
>>>> jbosscache-pojo.jar
>>>> jgroups.jar
>>>>
>>>> The new directory is added to the classpath in conf/jboss-service.xml:
>>>>
>>>> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
>>>> <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
>>>>
>>>> The minimal config remains unchanged.
>>>>
>>>> https://jira.jboss.org/jira/browse/JBAS-6158
>>>>
>>>> You probably need to cleanup your build/output/** directory to pick
>>>> up the change at your next svn update.
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
7:50 p.m.
Aleksandar Kostadinov wrote:
So you're saying the approach I suggest is *fundamentally*
flawed? See
below why I don't agree. I just opt for a better temporary solution so
we don't have to deal with the current for a long time. If too hard
then I'm ok with that.
Let me summarize what I don't like in current server/lib approach and
I hope that to be my last mail.
1. repurposing servers directory (I think better would be
JBOSS_HOME/shared or something)
That was Dimitris original proposal as well, so it
seem like what most
agree on.
2. will possibly be hardly reusable for additional server
configurations (imagine if we want one less lib in the configuration)
+ leads again to duplication of libs in the distribution (although
much less).
The server config can choose to not include a jar from the shared lib
directory. We have not really talked about how the shared/lib contents
are included in what traditionally was a server/xxx/lib/* wildcard
inclusion of everything. A classpath element that allows for wildard
inclusion as well as exclusion would allow a server config to use any
set of shared jars.
3. one can't easily change a bundled library only in one configuration
for some test purposes (imagine security update testing)
Also addressed by a more flexible classpath notion.
9:40 a.m.
So I think I'll move this to a top-level directory.
Any preferences between
JBOSS_HOME/common/lib
vs
JBOSS_HOME/shared/lib?
Scott Stark wrote:
Aleksandar Kostadinov wrote:
> So you're saying the approach I suggest is *fundamentally* flawed? See
> below why I don't agree. I just opt for a better temporary solution so
> we don't have to deal with the current for a long time. If too hard
> then I'm ok with that.
>
> Let me summarize what I don't like in current server/lib approach and
> I hope that to be my last mail.
> 1. repurposing servers directory (I think better would be
> JBOSS_HOME/shared or something)
That was Dimitris original proposal as well, so it seem like what most
agree on.
> 2. will possibly be hardly reusable for additional server
> configurations (imagine if we want one less lib in the configuration)
> + leads again to duplication of libs in the distribution (although
> much less).
The server config can choose to not include a jar from the shared lib
directory. We have not really talked about how the shared/lib contents
are included in what traditionally was a server/xxx/lib/* wildcard
inclusion of everything. A classpath element that allows for wildard
inclusion as well as exclusion would allow a server config to use any
set of shared jars.
>
> 3. one can't easily change a bundled library only in one configuration
> for some test purposes (imagine security update testing)
>
Also addressed by a more flexible classpath notion.
3:55 p.m.
Dimitris Andreadis wrote:
Any preferences between
JBOSS_HOME/common/lib
vs
JBOSS_HOME/shared/lib?
Both bring to mind the Tomcat 5.5 and earlier $CATALINA_HOME/common/lib
and $CATALINA_HOME/shared/lib. Probably will have the same association
for others, so I recommend we consider the meaning of those and try to
be consistent.
Those directories each serves as a resource location for a classloader,
described as follows [1]:
Common - This class loader contains additional classes that are made
visible to both Tomcat internal classes and to all web applications.
Normally, application classes should NOT be placed here.
Shared - This class loader is the place to put classes and resources
that you wish to share across ALL web applications (unless Tomcat
internal classes also need access, in which case you should put them in
the Common class loader instead).
Neither of those descriptions exactly matches the JBoss directory, since
"application classes should NOT be placed " in $JBOSS_HOME/common/lib
isn't technically true. But still, I think "common" better matches what
we are trying to do, since jars placed in it are most definitely meant
to be visible to internal JBoss classes.
Note that in Tomcat 6, common/lib and shared/lib are gone, with
common/lib functionally replaced by a plain lib/ [2]
[1] http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html
[2] http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
11:53 p.m.
Ok, so after this discussion the shared library directory has moved to
JBOSS_HOME/common/lib.
2 new properties were introduced:
- jboss.common.base.url defaulting to ${jboss.home.url}/common
- jboss.common.lib.url defaulting to ${jboss.common.base.url}/lib
(In case we want to introduce other common stuff, configuration or otherwise)
The jboss.shared.lib.url references were removed.
Cheers
/Dimitris
PS
Andrew, maybe you want to re-synch the forked bootstrap project.
Brian Stansberry wrote:
Dimitris Andreadis wrote:
> Any preferences between
>
> JBOSS_HOME/common/lib
> vs
> JBOSS_HOME/shared/lib?
>
Both bring to mind the Tomcat 5.5 and earlier $CATALINA_HOME/common/lib
and $CATALINA_HOME/shared/lib. Probably will have the same association
for others, so I recommend we consider the meaning of those and try to
be consistent.
Those directories each serves as a resource location for a classloader,
described as follows [1]:
Common - This class loader contains additional classes that are made
visible to both Tomcat internal classes and to all web applications.
Normally, application classes should NOT be placed here.
Shared - This class loader is the place to put classes and resources
that you wish to share across ALL web applications (unless Tomcat
internal classes also need access, in which case you should put them in
the Common class loader instead).
Neither of those descriptions exactly matches the JBoss directory, since
"application classes should NOT be placed " in $JBOSS_HOME/common/lib
isn't technically true. But still, I think "common" better matches what
we are trying to do, since jars placed in it are most definitely meant
to be visible to internal JBoss classes.
Note that in Tomcat 6, common/lib and shared/lib are gone, with
common/lib functionally replaced by a plain lib/ [2]
[1] http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html
[2] http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
12:03 a.m.
Dimitris Andreadis wrote:
Ok, so after this discussion the shared library directory has moved
to
JBOSS_HOME/common/lib.
2 new properties were introduced:
- jboss.common.base.url defaulting to ${jboss.home.url}/common
- jboss.common.lib.url defaulting to ${jboss.common.base.url}/lib
(In case we want to introduce other common stuff, configuration or
otherwise)
The jboss.shared.lib.url references were removed.
Cheers
/Dimitris
PS
Andrew, maybe you want to re-synch the forked bootstrap project.
Yes, and the EJB3 Plugin installer.
Is there a JBAS JIRA for this new move?
S,
ALR
Brian Stansberry wrote:
> Dimitris Andreadis wrote:
>> Any preferences between
>>
>> JBOSS_HOME/common/lib
>> vs
>> JBOSS_HOME/shared/lib?
>>
>
> Both bring to mind the Tomcat 5.5 and earlier $CATALINA_HOME/common/lib
> and $CATALINA_HOME/shared/lib. Probably will have the same association
> for others, so I recommend we consider the meaning of those and try to
> be consistent.
>
> Those directories each serves as a resource location for a
> classloader, described as follows [1]:
>
> Common - This class loader contains additional classes that are made
> visible to both Tomcat internal classes and to all web applications.
> Normally, application classes should NOT be placed here.
>
> Shared - This class loader is the place to put classes and resources
> that you wish to share across ALL web applications (unless Tomcat
> internal classes also need access, in which case you should put them
> in the Common class loader instead).
>
>
> Neither of those descriptions exactly matches the JBoss directory,
> since "application classes should NOT be placed " in
> $JBOSS_HOME/common/lib isn't technically true. But still, I think
> "common" better matches what we are trying to do, since jars placed in
> it are most definitely meant to be visible to internal JBoss classes.
>
> Note that in Tomcat 6, common/lib and shared/lib are gone, with
> common/lib functionally replaced by a plain lib/ [2]
>
> [1] http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html
> [2] http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
>
>
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
8:21 a.m.
The original: https://jira.jboss.org/jira/browse/JBAS-6158
Andrew Lee Rubinger wrote:
Dimitris Andreadis wrote:
> PS
> Andrew, maybe you want to re-synch the forked bootstrap project.
Yes, and the EJB3 Plugin installer.
Is there a JBAS JIRA for this new move?
S,
ALR
7:53 a.m.
I can't tell if its something in this change or the profileservice
default change(although I ran all the tests), but the security manager
tests are not starting now because the jboss.server.base.dir system
property is not being defined, and the profile cannot be loaded:
*** DEPLOYMENTS IN ERROR: Name -> Error
ProfileService -> org.jboss.profileservice.spi.NoSuchProfileException:
Profile root does not exists:
/home/svn/JBossHead/jboss-head/testsuite/${jboss.server.base.dir}/default
I'm looking at why that is.
Dimitris Andreadis wrote:
Ok, so after this discussion the shared library directory has moved
to
JBOSS_HOME/common/lib.
2 new properties were introduced:
- jboss.common.base.url defaulting to ${jboss.home.url}/common
- jboss.common.lib.url defaulting to ${jboss.common.base.url}/lib
(In case we want to introduce other common stuff, configuration or
otherwise)
The jboss.shared.lib.url references were removed.
Cheers
/Dimitris
PS
Andrew, maybe you want to re-synch the forked bootstrap project.
Brian Stansberry wrote:
> Dimitris Andreadis wrote:
>> Any preferences between
>>
>> JBOSS_HOME/common/lib
>> vs
>> JBOSS_HOME/shared/lib?
>>
>
> Both bring to mind the Tomcat 5.5 and earlier $CATALINA_HOME/common/lib
> and $CATALINA_HOME/shared/lib. Probably will have the same
> association for others, so I recommend we consider the meaning of
> those and try to be consistent.
>
> Those directories each serves as a resource location for a
> classloader, described as follows [1]:
>
> Common - This class loader contains additional classes that are made
> visible to both Tomcat internal classes and to all web applications.
> Normally, application classes should NOT be placed here.
>
> Shared - This class loader is the place to put classes and resources
> that you wish to share across ALL web applications (unless Tomcat
> internal classes also need access, in which case you should put them
> in the Common class loader instead).
>
>
> Neither of those descriptions exactly matches the JBoss directory,
> since "application classes should NOT be placed " in
> $JBOSS_HOME/common/lib isn't technically true. But still, I think
> "common" better matches what we are trying to do, since jars placed
> in it are most definitely meant to be visible to internal JBoss classes.
>
> Note that in Tomcat 6, common/lib and shared/lib are gone, with
> common/lib functionally replaced by a plain lib/ [2]
>
> [1] http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html
> [2] http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
>
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
8:07 a.m.
It has to do with the -Djboss.server.home.dir being set on the server
command line. We only set the jboss.server.base.dir as a side effect of
building the jboss.server.home.dir in getServerHomeDir(). If the
jboss.server.home.dir is already set, then nothing is calling
getServerBaseDir() to set the jboss.server.base.dir. All of these values
need to be set during the BaseServerConfig initialization.
Scott Stark wrote:
I can't tell if its something in this change or the
profileservice
default change(although I ran all the tests), but the security manager
tests are not starting now because the jboss.server.base.dir system
property is not being defined, and the profile cannot be loaded:
*** DEPLOYMENTS IN ERROR: Name -> Error
ProfileService -> org.jboss.profileservice.spi.NoSuchProfileException:
Profile root does not exists:
/home/svn/JBossHead/jboss-head/testsuite/${jboss.server.base.dir}/default
I'm looking at why that is.
8:20 a.m.
Its running again after this change:
commit -m "Make sure all of the ServerConfig values are accessed to set
the associated system property"
/Users/svn/JBossHead/jboss-head/bootstrap/src/main/org/jboss/bootstrap/AbstractServerImpl.java
Sending
/Users/svn/JBossHead/jboss-head/bootstrap/src/main/org/jboss/bootstrap/AbstractServerImpl.java
Transmitting file data ...
Committed revision 80920.
Scott Stark wrote:
It has to do with the -Djboss.server.home.dir being set on the server
command line. We only set the jboss.server.base.dir as a side effect
of building the jboss.server.home.dir in getServerHomeDir(). If the
jboss.server.home.dir is already set, then nothing is calling
getServerBaseDir() to set the jboss.server.base.dir. All of these
values need to be set during the BaseServerConfig initialization.
3:41 p.m.
Last evening, I did check in the updated policy for sec mgr (common/lib
change). That should get the AS sec mgr target going forward.
Scott Stark wrote:
I can't tell if its something in this change or the
profileservice
default change(although I ran all the tests), but the security manager
tests are not starting now because the jboss.server.base.dir system
property is not being defined, and the profile cannot be loaded:
*** DEPLOYMENTS IN ERROR: Name -> Error
ProfileService -> org.jboss.profileservice.spi.NoSuchProfileException:
Profile root does not exists:
/home/svn/JBossHead/jboss-head/testsuite/${jboss.server.base.dir}/default
I'm looking at why that is.
Dimitris Andreadis wrote:
> Ok, so after this discussion the shared library directory has moved
> to JBOSS_HOME/common/lib.
>
> 2 new properties were introduced:
>
> - jboss.common.base.url defaulting to ${jboss.home.url}/common
> - jboss.common.lib.url defaulting to ${jboss.common.base.url}/lib
>
> (In case we want to introduce other common stuff, configuration or
> otherwise)
>
> The jboss.shared.lib.url references were removed.
>
> Cheers
> /Dimitris
>
> PS
> Andrew, maybe you want to re-synch the forked bootstrap project.
>
> Brian Stansberry wrote:
>> Dimitris Andreadis wrote:
>>> Any preferences between
>>>
>>> JBOSS_HOME/common/lib
>>> vs
>>> JBOSS_HOME/shared/lib?
>>>
>>
>> Both bring to mind the Tomcat 5.5 and earlier $CATALINA_HOME/common/lib
>> and $CATALINA_HOME/shared/lib. Probably will have the same
>> association for others, so I recommend we consider the meaning of
>> those and try to be consistent.
>>
>> Those directories each serves as a resource location for a
>> classloader, described as follows [1]:
>>
>> Common - This class loader contains additional classes that are made
>> visible to both Tomcat internal classes and to all web applications.
>> Normally, application classes should NOT be placed here.
>>
>> Shared - This class loader is the place to put classes and resources
>> that you wish to share across ALL web applications (unless Tomcat
>> internal classes also need access, in which case you should put them
>> in the Common class loader instead).
>>
>>
>> Neither of those descriptions exactly matches the JBoss directory,
>> since "application classes should NOT be placed " in
>> $JBOSS_HOME/common/lib isn't technically true. But still, I think
>> "common" better matches what we are trying to do, since jars placed
>> in it are most definitely meant to be visible to internal JBoss
>> classes.
>>
>> Note that in Tomcat 6, common/lib and shared/lib are gone, with
>> common/lib functionally replaced by a plain lib/ [2]
>>
>> [1] http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html
>> [2] http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
>>
5:40 p.m.
Why not use the Maven repo? Then the initial download becomes really
small and dependencies are just loaded from the local repository.
Dimitris Andreadis wrote:
JBOSS_HOME/lib is our bootstrap directory so we wouldn't add
shared
libs there. And any new directory we introduce will break scripts anyway.
The only point of discussion is whether to put all libs in server/lib
and reference them explicitly, or put only the shared ones and
reference them implicitly.
The down side for referencing explicitly the chosen libs is that it is
harder to maintain, since whenever a lib is added you'd have to update
all affected configurations.
The up side is that you have a single lib dir for server libs.
Aleksandar Kostadinov wrote:
> I'm not the best one to give opinion on that but here it is.
>
> The change will complicate things and confuse users. As well doesn't
> seem scalable to me. When we have more server configurations, we'll
> need more lib directories (platforms more affected)... The change
> could break user utilities that expect the old layout, etc.
>
> IMHO a straightforward approach will be to remove the
> JBOSS_HOME/server/*/lib directories altogether and have all libraries
> in JBOSS_HOME/lib or another directory. Then appropriate libraries
> for every server configuration be selected in a configuration file
> (conf/jboss-service.xml?).
>
> Best Regards,
> Aleksandar
>
> Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
>> The new JBOSS_HOME/server/lib directory pointed to at by the
>> jboss.shared.lib.url property currently contains the libraries
>> shared by the default and all configurations.
>>
>> So server/default/lib is now empty and server/all/lib contains only:
>>
>> avalon-framework.jar
>> hibernate-jbosscache2.jar
>> jacorb.jar
>> jbosscache-core.jar
>> jbosscache-pojo.jar
>> jgroups.jar
>>
>> The new directory is added to the classpath in conf/jboss-service.xml:
>>
>> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
>> <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
>>
>> The minimal config remains unchanged.
>>
>> https://jira.jboss.org/jira/browse/JBAS-6158
>>
>> You probably need to cleanup your build/output/** directory to pick
>> up the change at your next svn update.
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
5:23 p.m.
On Tue, 2008-11-04 at 11:40 -0500, Stan Silvert wrote:
Why not use the Maven repo? Then the initial download becomes really
small and dependencies are just loaded from the local repository.
That is the future solution. Which is why I quoted "OBR"
in an earlier post. It really just means loading the jars
"on demand" from some a versioned source.
The actual source of the jars doesn't matter, all we should require
is a versioned repository (or list/hierarchy of them).
It then becomes possible to have a jboss distribution that
includes a local repository of jars or a smaller one
with minimal code that allows you to get them from
where ever you want.
The problem at the moment is not that we don't know how to
do this, the problem is that none of our services specify
what jars they actually need (not even the name, let alone the
version :-).
Dimitris Andreadis wrote:
> JBOSS_HOME/lib is our bootstrap directory so we wouldn't add shared
> libs there. And any new directory we introduce will break scripts anyway.
>
> The only point of discussion is whether to put all libs in server/lib
> and reference them explicitly, or put only the shared ones and
> reference them implicitly.
>
> The down side for referencing explicitly the chosen libs is that it is
> harder to maintain, since whenever a lib is added you'd have to update
> all affected configurations.
>
> The up side is that you have a single lib dir for server libs.
>
> Aleksandar Kostadinov wrote:
>> I'm not the best one to give opinion on that but here it is.
>>
>> The change will complicate things and confuse users. As well doesn't
>> seem scalable to me. When we have more server configurations, we'll
>> need more lib directories (platforms more affected)... The change
>> could break user utilities that expect the old layout, etc.
>>
>> IMHO a straightforward approach will be to remove the
>> JBOSS_HOME/server/*/lib directories altogether and have all libraries
>> in JBOSS_HOME/lib or another directory. Then appropriate libraries
>> for every server configuration be selected in a configuration file
>> (conf/jboss-service.xml?).
>>
>> Best Regards,
>> Aleksandar
>>
>> Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
>>> The new JBOSS_HOME/server/lib directory pointed to at by the
>>> jboss.shared.lib.url property currently contains the libraries
>>> shared by the default and all configurations.
>>>
>>> So server/default/lib is now empty and server/all/lib contains only:
>>>
>>> avalon-framework.jar
>>> hibernate-jbosscache2.jar
>>> jacorb.jar
>>> jbosscache-core.jar
>>> jbosscache-pojo.jar
>>> jgroups.jar
>>>
>>> The new directory is added to the classpath in conf/jboss-service.xml:
>>>
>>> <classpath codebase="${jboss.server.lib.url}"
archives="*"/>
>>> <classpath codebase="${jboss.shared.lib.url}"
archives="*"/>
>>>
>>> The minimal config remains unchanged.
>>>
>>> https://jira.jboss.org/jira/browse/JBAS-6158
>>>
>>> You probably need to cleanup your build/output/** directory to pick
>>> up the change at your next svn update.
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
5644
days inactive
5653
days old
jboss-development@lists.jboss.org
26 comments
11 participants
participants (11)
-
Adrian Brock -
Aleksandar Kostadinov -
Ales Justin -
Andrew Lee Rubinger -
Anil Saldhana -
Brian Stansberry -
Dimitris Andreadis -
Johnson, Peter -
Sacha Labourey -
Scott Stark -
Stan Silvert