OFBiz › OFBiz - Dev

Dev - More on Infrastructure (JOTM/Minerva vs Geronimo, etc)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

David E. Jones

Dev - More on Infrastructure (JOTM/Minerva vs Geronimo, etc)

I spent a few hours today researching Geronimo, mainly because it
seems to be the best candidate as an alternative to the current tools
we are using, which have some licensing issues (JOTM and Minerva).
With Minerva there is also a disadvantage that we are stuck
maintaining it. After a few bug fixes early on everything seems to be
okay with it, but the license clearance for use in the Apache-ized
OFBiz will be trickier.

Anyway, I could sum up research into Geronimo as a fresh bad taste in
my mouth. It's been over 2 years since we moved to our own container/
component infrastructure so that J2EE implementation modules would
run inside OFBiz instead of OFBiz running inside an app server. I was
really hoping that in that time the standards would improve. They
haven't. I was also hoping that at least in Geronimo we would find
that the always necessary proprietary extensions (because the core
standards are woefully inadequate) to be more convenient.

All we really want is to have an application that includes a set of
lower level tools, web applications, etc in a single package that is
easy to deploy, even for someone that is not technical nor familiar
with how the lower level tools are organized or built. That was the
main goal with the OFBiz component stuff, and it has been great to
work with for the last couple of years.

Back to Geronimo: using an EAR file (which can be deployed "exploded"
or in a directory instead of an EAR zip file) gets us pretty close,
and with the Geronimo proprietary extensions we can refer to general
jar files (don't seem to be able to do exploded directories of
classpath resources... would have to try that), but the problem is
they can't be inside the EAR... It's really frustrating that they
have gone with one of the things that I so didn't like about Tomcat
that it was one of the big reasons we used Jetty for a long time:
that you must copy the jar files into their directories instead of
referring to them where they live "naturally".

So, we could ship with Geronimo instead of the container stuff, but
we have various classpath issues to resolve. We could take all of the
third party libraries we use and put them under the geronimo/
repository directory using their directory organization conventions,
and then in the OFBiz build have it drop all jars it makes under the
geronimo/repository directory, and then refer to those in probably 2
EARs (one for framework, one for application that would depend on the
framework EAR).

There is some more unpleasantness... If we can't find a way to refer
to certain directories in their current locations but instead are
forced to put them in a jar file, we are going to lose some
convenient change and retry stuff we can do now, mainly with the
scripts on the classpath (all files in each component/script
directory, mostly simple-method XML files). This whole classpath
thing in an app server is messy enough that it would be nice to get
everything _off_ the classpath that we can. In other words, we'd move
to directories relative to a component home directory instead of on
the classpath. This would require a fair number of changes, like the
location of every single simple-method location in their service
definitions.

It would be really nice to have an easy way to deploy in other app
servers, but the standards bodies are not being overly helpful...
Short of that, it would at least be nice to deploy easily deploy in a
certain app server that we can deliver with OFBiz for easier out of
the box usage, since probably the majority (head count wise) of OFBiz
users just use it out of the box rather than deploying it in a
separate app server, and most of us would probably prefer to not have
to deal with the app server configuration and deployment...

Anyway, that's my rant for today. I've been trying to think of
creative ways around this... For example:

1. Use the lower-level Geronimo jars embedded in OFBiz, kind of like
the JOTM, etc jars are. This has the unfortunate disadvantage that
these don't appear to be designed for this, so it could be rather
tricky...

2. Create Geronimo-specific GBeans to do classloader changes in Java
code rather than configuration. This would be pretty non-standard and
experimental, and even if it did work initially it would be possible
for changes to be made in Geronimo that would break our stuff, or
perhaps require changes to our code (if we're lucky). I'm not sure if
this would even work... Right now we play with the classloader a LOT
on startup and my hope is that we could move this code over...

One way or another it would be nice to use the current config files
as-is to avoid redundancy, though that may not be possible. We may
have to have 2 lists of classpath resources and webapps and what not.
Actually that means we have to have one set for each app server, and
for each variation over time/versions of that app server. We tried
doing that once and it is a REAL MESS! I'd rather not go there again.

Andy has been working on this and communicating with some of the
Geronimo people. Hopefully we'll find a good resolution to this. If
anyone has any ideas or wants to help out with this, that would be
great.

I know Andy has some stuff to take care of some things, like I guess
some GBeans and such, and perhaps we can create a branch in SVN or a
set of resources that aren't being used by default (this would be my
preference to make it easier for people to play with it).

-David

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

smime.p7s (3K) Download Attachment

Adam Heath-2

Re: Dev - More on Infrastructure (JOTM/Minerva vs Geronimo, etc)

On Mon, 6 Mar 2006, David E. Jones wrote:

> There is some more unpleasantness... If we can't find a way to refer
> to certain directories in their current locations but instead are
> forced to put them in a jar file, we are going to lose some
> convenient change and retry stuff we can do now, mainly with the
> scripts on the classpath (all files in each component/script
> directory, mostly simple-method XML files). This whole classpath
> thing in an app server is messy enough that it would be nice to get
> everything _off_ the classpath that we can. In other words, we'd move
> to directories relative to a component home directory instead of on
> the classpath. This would require a fair number of changes, like the
> location of every single simple-method location in their service
> definitions.

Use commons-vfs for this, maybe?

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

Oleg Kozyrev Jr.

Re: Dev - More on Infrastructure (JOTM/Minerva vs Geronimo, etc)

In reply to this post by David E. Jones

Hello David,

I'm not really a specialist in Geronimo, but if I understand you correctly
your second "creative way" is to do something like here
http://wiki.apache.org/geronimo/Tomcat with one difference: integrate not
Tomcat, but OFBiz.

Am I right that you suggest this?

Oleg.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of David E. Jones
Sent: Monday, March 06, 2006 11:53 AM
To: OFBiz Project Development Discussion
Subject: [OFBiz] Dev - More on Infrastructure (JOTM/Minerva vs Geronimo,
etc)

I spent a few hours today researching Geronimo, mainly because it
seems to be the best candidate as an alternative to the current tools
we are using, which have some licensing issues (JOTM and Minerva).
With Minerva there is also a disadvantage that we are stuck
maintaining it. After a few bug fixes early on everything seems to be
okay with it, but the license clearance for use in the Apache-ized
OFBiz will be trickier.

Anyway, I could sum up research into Geronimo as a fresh bad taste in
my mouth. It's been over 2 years since we moved to our own container/
component infrastructure so that J2EE implementation modules would
run inside OFBiz instead of OFBiz running inside an app server. I was
really hoping that in that time the standards would improve. They
haven't. I was also hoping that at least in Geronimo we would find
that the always necessary proprietary extensions (because the core
standards are woefully inadequate) to be more convenient.

All we really want is to have an application that includes a set of
lower level tools, web applications, etc in a single package that is
easy to deploy, even for someone that is not technical nor familiar
with how the lower level tools are organized or built. That was the
main goal with the OFBiz component stuff, and it has been great to
work with for the last couple of years.

Back to Geronimo: using an EAR file (which can be deployed "exploded"
or in a directory instead of an EAR zip file) gets us pretty close,
and with the Geronimo proprietary extensions we can refer to general
jar files (don't seem to be able to do exploded directories of
classpath resources... would have to try that), but the problem is
they can't be inside the EAR... It's really frustrating that they
have gone with one of the things that I so didn't like about Tomcat
that it was one of the big reasons we used Jetty for a long time:
that you must copy the jar files into their directories instead of
referring to them where they live "naturally".

So, we could ship with Geronimo instead of the container stuff, but
we have various classpath issues to resolve. We could take all of the
third party libraries we use and put them under the geronimo/
repository directory using their directory organization conventions,
and then in the OFBiz build have it drop all jars it makes under the
geronimo/repository directory, and then refer to those in probably 2
EARs (one for framework, one for application that would depend on the
framework EAR).

There is some more unpleasantness... If we can't find a way to refer
to certain directories in their current locations but instead are
forced to put them in a jar file, we are going to lose some
convenient change and retry stuff we can do now, mainly with the
scripts on the classpath (all files in each component/script
directory, mostly simple-method XML files). This whole classpath
thing in an app server is messy enough that it would be nice to get
everything _off_ the classpath that we can. In other words, we'd move
to directories relative to a component home directory instead of on
the classpath. This would require a fair number of changes, like the
location of every single simple-method location in their service
definitions.

It would be really nice to have an easy way to deploy in other app
servers, but the standards bodies are not being overly helpful...
Short of that, it would at least be nice to deploy easily deploy in a
certain app server that we can deliver with OFBiz for easier out of
the box usage, since probably the majority (head count wise) of OFBiz
users just use it out of the box rather than deploying it in a
separate app server, and most of us would probably prefer to not have
to deal with the app server configuration and deployment...

Anyway, that's my rant for today. I've been trying to think of
creative ways around this... For example:

1. Use the lower-level Geronimo jars embedded in OFBiz, kind of like
the JOTM, etc jars are. This has the unfortunate disadvantage that
these don't appear to be designed for this, so it could be rather
tricky...

2. Create Geronimo-specific GBeans to do classloader changes in Java
code rather than configuration. This would be pretty non-standard and
experimental, and even if it did work initially it would be possible
for changes to be made in Geronimo that would break our stuff, or
perhaps require changes to our code (if we're lucky). I'm not sure if
this would even work... Right now we play with the classloader a LOT
on startup and my hope is that we could move this code over...

One way or another it would be nice to use the current config files
as-is to avoid redundancy, though that may not be possible. We may
have to have 2 lists of classpath resources and webapps and what not.
Actually that means we have to have one set for each app server, and
for each variation over time/versions of that app server. We tried
doing that once and it is a REAL MESS! I'd rather not go there again.

Andy has been working on this and communicating with some of the
Geronimo people. Hopefully we'll find a good resolution to this. If
anyone has any ideas or wants to help out with this, that would be
great.

I know Andy has some stuff to take care of some things, like I guess
some GBeans and such, and perhaps we can create a branch in SVN or a
set of resources that aren't being used by default (this would be my
preference to make it easier for people to play with it).

-David

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

David E. Jones

Re: Dev - More on Infrastructure (JOTM/Minerva vs Geronimo, etc)

Oleg,

Unfortunately this is closer to the un-creative way that Geronimo is
designed for it to be done than the "creative" way I had in mind that
would circumvent the Geronimo facilities for this.

The way Geronimo handles libraries is great for more static things
like infrastructure libraries. This would work for the OFBiz
framework libraries, though at times it would still be more
cumbersome than what we are currently doing and it would complicate
the build scripts by requiring a deployment step after the build
whereas now everything is "deployed" in place.

For the Java functionality in components this becomes a much bigger
mess because these need to be built and deployed frequently during
development and tend to change much more often. Treating them as
"system" libraries is very cumbersome.

So, the 2nd creative way I mentioned is really more along the lines
of writing Java code to do our own classloader configurations and
leave the files where they are and use the classpath elements defined
in the ofbiz-component.xml files at run-time (instead of in a pre-
running deployment step). This may get tricky though, or be
impossible, depending on how Geronimo handles their classloader
management in general...

-David

On Mar 7, 2006, at 11:24 AM, Oleg Kozyrev jr. wrote:

> Hello David,
>
> I'm not really a specialist in Geronimo, but if I understand you
> correctly
> your second "creative way" is to do something like here
> http://wiki.apache.org/geronimo/Tomcat with one difference:
> integrate not
> Tomcat, but OFBiz.
>
> Am I right that you suggest this?
>
> Oleg.
>
> -----Original Message-----
> From: [hidden email] [mailto:dev-
> [hidden email]] On
> Behalf Of David E. Jones
> Sent: Monday, March 06, 2006 11:53 AM
> To: OFBiz Project Development Discussion
> Subject: [OFBiz] Dev - More on Infrastructure (JOTM/Minerva vs
> Geronimo,
> etc)
>
>
> I spent a few hours today researching Geronimo, mainly because it
> seems to be the best candidate as an alternative to the current tools
> we are using, which have some licensing issues (JOTM and Minerva).
> With Minerva there is also a disadvantage that we are stuck
> maintaining it. After a few bug fixes early on everything seems to be
> okay with it, but the license clearance for use in the Apache-ized
> OFBiz will be trickier.
>
> Anyway, I could sum up research into Geronimo as a fresh bad taste in
> my mouth. It's been over 2 years since we moved to our own container/
> component infrastructure so that J2EE implementation modules would
> run inside OFBiz instead of OFBiz running inside an app server. I was
> really hoping that in that time the standards would improve. They
> haven't. I was also hoping that at least in Geronimo we would find
> that the always necessary proprietary extensions (because the core
> standards are woefully inadequate) to be more convenient.
>
> All we really want is to have an application that includes a set of
> lower level tools, web applications, etc in a single package that is
> easy to deploy, even for someone that is not technical nor familiar
> with how the lower level tools are organized or built. That was the
> main goal with the OFBiz component stuff, and it has been great to
> work with for the last couple of years.
>
> Back to Geronimo: using an EAR file (which can be deployed "exploded"
> or in a directory instead of an EAR zip file) gets us pretty close,
> and with the Geronimo proprietary extensions we can refer to general
> jar files (don't seem to be able to do exploded directories of
> classpath resources... would have to try that), but the problem is
> they can't be inside the EAR... It's really frustrating that they
> have gone with one of the things that I so didn't like about Tomcat
> that it was one of the big reasons we used Jetty for a long time:
> that you must copy the jar files into their directories instead of
> referring to them where they live "naturally".
>
> So, we could ship with Geronimo instead of the container stuff, but
> we have various classpath issues to resolve. We could take all of the
> third party libraries we use and put them under the geronimo/
> repository directory using their directory organization conventions,
> and then in the OFBiz build have it drop all jars it makes under the
> geronimo/repository directory, and then refer to those in probably 2
> EARs (one for framework, one for application that would depend on the
> framework EAR).
>
> There is some more unpleasantness... If we can't find a way to refer
> to certain directories in their current locations but instead are
> forced to put them in a jar file, we are going to lose some
> convenient change and retry stuff we can do now, mainly with the
> scripts on the classpath (all files in each component/script
> directory, mostly simple-method XML files). This whole classpath
> thing in an app server is messy enough that it would be nice to get
> everything _off_ the classpath that we can. In other words, we'd move
> to directories relative to a component home directory instead of on
> the classpath. This would require a fair number of changes, like the
> location of every single simple-method location in their service
> definitions.
>
> It would be really nice to have an easy way to deploy in other app
> servers, but the standards bodies are not being overly helpful...
> Short of that, it would at least be nice to deploy easily deploy in a
> certain app server that we can deliver with OFBiz for easier out of
> the box usage, since probably the majority (head count wise) of OFBiz
> users just use it out of the box rather than deploying it in a
> separate app server, and most of us would probably prefer to not have
> to deal with the app server configuration and deployment...
>
> Anyway, that's my rant for today. I've been trying to think of
> creative ways around this... For example:
>
> 1. Use the lower-level Geronimo jars embedded in OFBiz, kind of like
> the JOTM, etc jars are. This has the unfortunate disadvantage that
> these don't appear to be designed for this, so it could be rather
> tricky...
>
> 2. Create Geronimo-specific GBeans to do classloader changes in Java
> code rather than configuration. This would be pretty non-standard and
> experimental, and even if it did work initially it would be possible
> for changes to be made in Geronimo that would break our stuff, or
> perhaps require changes to our code (if we're lucky). I'm not sure if
> this would even work... Right now we play with the classloader a LOT
> on startup and my hope is that we could move this code over...
>
> One way or another it would be nice to use the current config files
> as-is to avoid redundancy, though that may not be possible. We may
> have to have 2 lists of classpath resources and webapps and what not.
> Actually that means we have to have one set for each app server, and
> for each variation over time/versions of that app server. We tried
> doing that once and it is a REAL MESS! I'd rather not go there again.
>
> Andy has been working on this and communicating with some of the
> Geronimo people. Hopefully we'll find a good resolution to this. If
> anyone has any ideas or wants to help out with this, that would be
> great.
>
> I know Andy has some stuff to take care of some things, like I guess
> some GBeans and such, and perhaps we can create a branch in SVN or a
> set of resources that aren't being used by default (this would be my
> preference to make it easier for people to play with it).
>
> -David
>
>
>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

Oleg Kozyrev Jr.

Re: Dev - More on Infrastructure (JOTM/Minerva vs Geronimo, etc)

David,

Just several notes.
1. I've read somewhere that WebSphere Application Server Community Edition
is build over Apache Geronimo. It is open source, so we can see how
everything is organized there.
2. There is a book about Geronimo:
http://www.chariotsolutions.com/geronimo/geronimo-html-toc.html
I haven't read it much, but hope it will help.

Oleg.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of David E. Jones
Sent: Saturday, March 11, 2006 10:27 AM
To: OFBiz Project Development Discussion
Subject: Re: [OFBiz] Dev - More on Infrastructure (JOTM/Minerva vs
Geronimo,etc)

Oleg,

Unfortunately this is closer to the un-creative way that Geronimo is
designed for it to be done than the "creative" way I had in mind that
would circumvent the Geronimo facilities for this.

The way Geronimo handles libraries is great for more static things
like infrastructure libraries. This would work for the OFBiz
framework libraries, though at times it would still be more
cumbersome than what we are currently doing and it would complicate
the build scripts by requiring a deployment step after the build
whereas now everything is "deployed" in place.

For the Java functionality in components this becomes a much bigger
mess because these need to be built and deployed frequently during
development and tend to change much more often. Treating them as
"system" libraries is very cumbersome.

So, the 2nd creative way I mentioned is really more along the lines
of writing Java code to do our own classloader configurations and
leave the files where they are and use the classpath elements defined
in the ofbiz-component.xml files at run-time (instead of in a pre-
running deployment step). This may get tricky though, or be
impossible, depending on how Geronimo handles their classloader
management in general...

-David

On Mar 7, 2006, at 11:24 AM, Oleg Kozyrev jr. wrote:

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

bjc

Re: Dev - More on Infrastructure (JOTM/Minerva vs Geronimo, etc)

Hi all - sorry to just appear without introducing myself, but I
wanted to throw in my 2 cents and then I've got to rush out the door!

On Mar 12, 2006, at 9:08 AM, Oleg Kozyrev jr. wrote:

> So, the 2nd creative way I mentioned is really more along the lines
> of writing Java code to do our own classloader configurations and
> leave the files where they are and use the classpath elements defined
> in the ofbiz-component.xml files at run-time (instead of in a pre-
> running deployment step). This may get tricky though, or be
> impossible, depending on how Geronimo handles their classloader
> management in general...
>
> -David
>

The Rife web application framework does something similar to what you
are describing here, wherein the files that Rife uses to create it's
view of the world are resolved at runtime through it's own
classloader. Check out the Sources from http://www.rifers.org/
downloads and look for the EngineClassLoader to get some idea of how
he did this.

Disclaimer: I am in no way affiliated with Rife, except that I used
it once :-)

Ben

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

Jacopo Cappellato

Re: Dev - More on Infrastructure (JOTM/Minerva vs Geronimo, etc)

In reply to this post by David E. Jones

David,

thanks for the updates.

Just my two cents:

I really think that your #1 approach is definitely the way we should try
to follow: I don't know how difficult (if even possible) it will be to
pull the transaction and connection managers from Geronimo and use them
instead of JOTM and Minerva but I see several advantages in this approach:

1) keep untouched the well-proven (container) architecture of OFBiz
2) the work needed to refactor the transaction and connection managers
to make them Geronimo-indipendent, could be done in the Geronimo
codebase/project: once done, we will simply (maybe the word *simply* is
not appropriate here...) pull the the two components (jars?) from
Geronimo and plug them into OFBiz (no additional code to manage in OFBiz)
3) I'm sure that making the Geronimo's transaction and connection
managers pluggable will be of interest for other projects too: so we
could probably get help from others and from the Geronimo dev team too
(more projects using their jars means more tests, more stability etc...)

What kind of feedback (if any) did Andy get from the Geronimo's guys?

That said, it would be very nice in the future to (optionally) provide a
*light* OFBiz distribution: something that can be deployed into an
existing Geronimo instance by an additional ant task... in this way
Geronimo+OFBiz will be a complete ERP system good also for big companies.

Jacopo

David E.Jones wrote:

>
> I spent a few hours today researching Geronimo, mainly because it seems
> to be the best candidate as an alternative to the current tools we are
> using, which have some licensing issues (JOTM and Minerva). With Minerva
> there is also a disadvantage that we are stuck maintaining it. After a
> few bug fixes early on everything seems to be okay with it, but the
> license clearance for use in the Apache-ized OFBiz will be trickier.
>
> Anyway, I could sum up research into Geronimo as a fresh bad taste in my
> mouth. It's been over 2 years since we moved to our own
> container/component infrastructure so that J2EE implementation modules
> would run inside OFBiz instead of OFBiz running inside an app server. I
> was really hoping that in that time the standards would improve. They
> haven't. I was also hoping that at least in Geronimo we would find that
> the always necessary proprietary extensions (because the core standards
> are woefully inadequate) to be more convenient.
>
> All we really want is to have an application that includes a set of
> lower level tools, web applications, etc in a single package that is
> easy to deploy, even for someone that is not technical nor familiar with
> how the lower level tools are organized or built. That was the main goal
> with the OFBiz component stuff, and it has been great to work with for
> the last couple of years.
>
> Back to Geronimo: using an EAR file (which can be deployed "exploded" or
> in a directory instead of an EAR zip file) gets us pretty close, and
> with the Geronimo proprietary extensions we can refer to general jar
> files (don't seem to be able to do exploded directories of classpath
> resources... would have to try that), but the problem is they can't be
> inside the EAR... It's really frustrating that they have gone with one
> of the things that I so didn't like about Tomcat that it was one of the
> big reasons we used Jetty for a long time: that you must copy the jar
> files into their directories instead of referring to them where they
> live "naturally".
>
> So, we could ship with Geronimo instead of the container stuff, but we
> have various classpath issues to resolve. We could take all of the third
> party libraries we use and put them under the geronimo/repository
> directory using their directory organization conventions, and then in
> the OFBiz build have it drop all jars it makes under the
> geronimo/repository directory, and then refer to those in probably 2
> EARs (one for framework, one for application that would depend on the
> framework EAR).
>
> There is some more unpleasantness... If we can't find a way to refer to
> certain directories in their current locations but instead are forced to
> put them in a jar file, we are going to lose some convenient change and
> retry stuff we can do now, mainly with the scripts on the classpath (all
> files in each component/script directory, mostly simple-method XML
> files). This whole classpath thing in an app server is messy enough that
> it would be nice to get everything _off_ the classpath that we can. In
> other words, we'd move to directories relative to a component home
> directory instead of on the classpath. This would require a fair number
> of changes, like the location of every single simple-method location in
> their service definitions.
>
> It would be really nice to have an easy way to deploy in other app
> servers, but the standards bodies are not being overly helpful... Short
> of that, it would at least be nice to deploy easily deploy in a certain
> app server that we can deliver with OFBiz for easier out of the box
> usage, since probably the majority (head count wise) of OFBiz users just
> use it out of the box rather than deploying it in a separate app server,
> and most of us would probably prefer to not have to deal with the app
> server configuration and deployment...
>
> Anyway, that's my rant for today. I've been trying to think of creative
> ways around this... For example:
>
> 1. Use the lower-level Geronimo jars embedded in OFBiz, kind of like the
> JOTM, etc jars are. This has the unfortunate disadvantage that these
> don't appear to be designed for this, so it could be rather tricky...
>
> 2. Create Geronimo-specific GBeans to do classloader changes in Java
> code rather than configuration. This would be pretty non-standard and
> experimental, and even if it did work initially it would be possible for
> changes to be made in Geronimo that would break our stuff, or perhaps
> require changes to our code (if we're lucky). I'm not sure if this would
> even work... Right now we play with the classloader a LOT on startup and
> my hope is that we could move this code over...
>
> One way or another it would be nice to use the current config files
> as-is to avoid redundancy, though that may not be possible. We may have
> to have 2 lists of classpath resources and webapps and what not.
> Actually that means we have to have one set for each app server, and for
> each variation over time/versions of that app server. We tried doing
> that once and it is a REAL MESS! I'd rather not go there again.
>
> Andy has been working on this and communicating with some of the
> Geronimo people. Hopefully we'll find a good resolution to this. If
> anyone has any ideas or wants to help out with this, that would be great.
>
> I know Andy has some stuff to take care of some things, like I guess
> some GBeans and such, and perhaps we can create a branch in SVN or a set
> of resources that aren't being used by default (this would be my
> preference to make it easier for people to play with it).
>
> -David
>
>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev