Geronimo has been around for a while and despite the many good
features gbeans and the geronimo kernel are not catching on big time.
I think we want to consider taking action now to avoid ending up being
dragged down by supporting a dead container. Here are a few thoughts.
Actual problems
It is a good idea.
I encounter some similar issues about the multiparent classloader. From the
pom.xml, currently, it is hard to know which jar is in the classpath. The
dependies between the configurations are also too complex, I notice that the
restart/reload codes in the configurationManager is v
This is defintely a good move! How will that affect the programming model
around Geronimo? Obviously some users are not happy with the complexity of
the deployment plan [1].
-Jack
[1]
http://www.nabble.com/your-current-Geronimo-evaluation-td22329850s134.html
2009/3/5 Ivan
> It is a good idea.
We've spoken about this, in the past. I'm certainly in favor of
exploring this...
On Mar 4, 2009, at 7:56 PM, David Jencks wrote:
Geronimo has been around for a while and despite the many good
features gbeans and the geronimo kernel are not catching on big
time. I think we want to conside
The one difficulty I see in moving from the current Geronimo
classloading model to the OSGi model is dealing with the change in
granularity. In the current model, the granularity is at the jar level
and using the one-classloader-per-jar model, you get all of the classes
contained in the jar.
Agree that it is time to start looking at OSGi and thanks for kicking
this off!
-Donald
David Jencks wrote:
Geronimo has been around for a while and despite the many good features
gbeans and the geronimo kernel are not catching on big time. I think we
want to consider taking action now to
Hi David, I think this is a good move and worthy investigation! I
have some comments below.
On Wed, Mar 4, 2009 at 7:56 PM, David Jencks wrote:
> Geronimo has been around for a while and despite the many good features
> gbeans and the geronimo kernel are not catching on big time. I think we
> w
want
to have to specify OSGI dependencies for JEE applications.
If there is OSGI below, fine. If I can use it, fine. But it should not be
necessary for standard JEE apps.
Thanks,
Juergen
--
View this message in context:
http://www.nabble.com/Whence-the-geronimo-kernel--tp22343125s134p22372881
for standard JEE apps.
>
> Thanks,
> Juergen
> --
> View this message in context:
> http://www.nabble.com/Whence-the-geronimo-kernel--tp22343125s134p22372881.html
> Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
>
>
On Mar 6, 2009, at 8:52 AM, Juergen Weber wrote:
I as user see Geronimo not as GBeans nor as OSGI server, I see it as
JEE
server.
So my requirements are to have a server
- that runs standard JEE applications
- without changes necessary
- on an Apache licensed server
Therefore the change to
gt;
> Thanks,
> Juergen
> --
> View this message in context:
> http://www.nabble.com/Whence-the-geronimo-kernel--tp22343125s134p22372881.html
> Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
>
>
So as mentioned below I'm starting to look into the osgi classloading
bit, sort of "from the bottom".
Another approach to many of these issues is perhaps "from the top",
from the point of view of going from a presumably xml plan to a bunch
of objects.
I've long thought that it must be pos
Hi,
FWIW, I believe that improving the configuration style to simplify
the means of creating a bunch of objects in the kernel has more
benefits than swapping the classloading infra. On paper OSGi may
appear as superior from a classloading isolation perspective;
however, I believe the curr
On Wed, Mar 11, 2009 at 08:57, Gianny Damour
wrote:
> Hi,
>
> FWIW, I believe that improving the configuration style to simplify the
> means of creating a bunch of objects in the kernel has more benefits than
> swapping the classloading infra. On paper OSGi may appear as superior from a
> classloa
Hi,
So let's agree to disagree for now. This may be related to my
personal way of comparing stuff which is pretty much limited to:
1. understand what the requirements are.
2. understand how the technologies support these requirements. I do
not need all the bells and whistles that a technolog
Guillaume Nodet wrote:
On Wed, Mar 11, 2009 at 08:57, Gianny Damour
mailto:gianny.dam...@optusnet.com.au>>
wrote:
Hi,
FWIW, I believe that improving the configuration style to simplify
the means of creating a bunch of objects in the kernel has more
benefits than swapping th
David Jencks wrote:
So as mentioned below I'm starting to look into the osgi classloading
bit, sort of "from the bottom".
Another approach to many of these issues is perhaps "from the top",
from the point of view of going from a presumably xml plan to a bunch
of objects.
I've long thought t
On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote:
Hi,
So let's agree to disagree for now. This may be related to my
personal way of comparing stuff which is pretty much limited to:
1. understand what the requirements are.
2. understand how the technologies support these requirements. I do
On Mar 11, 2009, at 12:57 AM, Gianny Damour wrote:
Hi,
FWIW, I believe that improving the configuration style to simplify
the means of creating a bunch of objects in the kernel has more
benefits than swapping the classloading infra. On paper OSGi may
appear as superior from a classloadin
On Wed, Mar 11, 2009 at 1:29 PM, David Jencks wrote:
>
> On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote:
>
>> Hi,
>>
>> So let's agree to disagree for now. This may be related to my personal way
>> of comparing stuff which is pretty much limited to:
>> 1. understand what the requirements are.
>>
On Mar 11, 2009, at 11:27 AM, Jarek Gawor wrote:
On Wed, Mar 11, 2009 at 1:29 PM, David Jencks
wrote:
On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote:
Hi,
So let's agree to disagree for now. This may be related to my
personal way
of comparing stuff which is pretty much limited to:
1.
On Wed, Mar 11, 2009 at 20:30, David Jencks wrote:
>
> On Mar 11, 2009, at 11:27 AM, Jarek Gawor wrote:
>
> On Wed, Mar 11, 2009 at 1:29 PM, David Jencks
>> wrote:
>>
>>>
>>> On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote:
>>>
>>> Hi,
So let's agree to disagree for now. This may be
On Wed, Mar 11, 2009 at 3:30 PM, David Jencks wrote:
>>
>> Right but that's an important problem which we run into all the time
>> in Geronimo (same jar loaded by two different classloaders). And the
>> solution to this problem is to create another
>> configuration/classloader and make that the pa
On Mar 12, 2009, at 1:26 AM, David Jencks wrote:
I believe that xbean-spring is still unnecessary noisy when
compared to something like the Spring Bean Builder (http://www.grails.org/Spring+Bean+Builder
).
That looks nice, but is there any syntax validation possible? I'm
pretty much unwill
On Mar 11, 2009, at 10:55 PM, Jason Dillon wrote:
On Mar 12, 2009, at 1:26 AM, David Jencks wrote:
I believe that xbean-spring is still unnecessary noisy when
compared to something like the Spring Bean Builder (http://www.grails.org/Spring+Bean+Builder
).
That looks nice, but is there any
On 12/03/2009, at 4:29 AM, David Jencks wrote:
On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote:
Hi,
So let's agree to disagree for now. This may be related to my
personal way of comparing stuff which is pretty much limited to:
1. understand what the requirements are.
2. understand how th
On 12/03/2009, at 5:26 AM, David Jencks wrote:
On Mar 11, 2009, at 12:57 AM, Gianny Damour wrote:
Hi,
FWIW, I believe that improving the configuration style to simplify
the means of creating a bunch of objects in the kernel has more
benefits than swapping the classloading infra. On paper
, March 12, 2009 12:25:34 PM
Subject: Re: Whence the geronimo kernel?
On 12/03/2009, at 4:29 AM, David Jencks wrote:
>
> On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote:
>
>> Hi,
>>
>> So let's agree to disagree for now. This may be related to my personal way
On Mar 12, 2009, at 3:25 AM, Gianny Damour wrote:
On 12/03/2009, at 4:29 AM, David Jencks wrote:
On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote:
Hi,
So let's agree to disagree for now. This may be related to my
personal way of comparing stuff which is pretty much limited to:
1. under
See comments below.
Lin
On Thu, Mar 12, 2009 at 1:51 AM, Jarek Gawor wrote:
> The point I was trying to make is that with Geronimo the classloader
> hierarchy is pretty much created/setup at build time while in osgi if
> you are using Import-Package is at runtime. Here's an example. Say, we
> ha
I think this is a valid concern. My understanding is that the OSGi
community is working hard on this as they are working on
specifications for a Web Container in OSGi with requirements like Java
EE compliant web container in OSGi. They are also working on
specifications for JNDI in OSGi, transac
On Mar 12, 2009, at 10:02 AM, David Jencks wrote:
On Mar 12, 2009, at 3:25 AM, Gianny Damour wrote:
On 12/03/2009, at 4:29 AM, David Jencks wrote:
On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote:
Hi,
So let's agree to disagree for now. This may be related to my
personal way of compa
I think I was not too clear below. I didn't mean to say that I am in
favor of Require-Bundle because it is a lot harder to come up with the
right Import-Package lists. What I meant was that the reason why a
lot of people are using Require-Bundle like David mentioned in his
early notes is probably
I read the blog entry and discussion. The entire discussion is
predicated on the idea that osgi is close to ideal as-is and we have
no need to consider any other point of view. If you step back a bit I
see two things clearly acknowledged by everyone:
1. its useful to be able to know what
"I certainly think claiming all we need is import-package is
shortchanging most of our experience in producing geronimo as a
working server." << +1000
-- dims
On Fri, Mar 13, 2009 at 12:27 PM, David Jencks wrote:
> I read the blog entry and discussion. The entire discussion is predicated
> on t
David Jencks wrote:
I read the blog entry and discussion. The entire discussion is
predicated on the idea that osgi is close to ideal as-is and we have
no need to consider any other point of view. If you step back a bit I
see two things clearly acknowledged by everyone:
1. its useful to be
On Mar 13, 2009, at 9:43 AM, Rick McGuire wrote:
David Jencks wrote:
I read the blog entry and discussion. The entire discussion is
predicated on the idea that osgi is close to ideal as-is and we
have no need to consider any other point of view. If you step back
a bit I see two things c
"At the moment I'm inclined to think that require-bundle is not a workable
solution for (2) and so we might as well use import-package plus an osgi
runtime that uses and requires explicit external dependency information such
as provided by maven or geronimo-plugin.xml to choose what bundle to resol
On 13/03/2009, at 6:44 PM, David Jencks wrote:
On Mar 12, 2009, at 10:02 AM, David Jencks wrote:
On Mar 12, 2009, at 3:25 AM, Gianny Damour wrote:
On 12/03/2009, at 4:29 AM, David Jencks wrote:
I think I probably have the most experience with classloading
problems in geronimo and the o
Rex,
If you follow the discussion closely, I think David was just saying
that he prefers to stay away from Require-Bundle for now, as the OSGi
specification doesn't recommend people to use it, along with the probs
people mentioned about it in the link I posted earlier.
I also found these links in
For those that are not aware of ServiceMix Kernel (I know David is), i'd
like to point them to it. Feel free to download it and give it a try. It's
based on felix, gshell and a few other bundles. We're using it to deploy our
JBI container in ServiceMix 4 (including the geronimo transaction manage
Thanks Lin,
I know the Issues with reqriring bundle(3.13.3 of spec 4.1), and the main
opposite point from the blog I think is just because of the "refactor".
I just want to make clear that, is there any situation we might meet the
split packages or refactor a bundle frequently?
At least, my eclipse
Hi Rex, I'm not Lin, but I thought I'd just add a few thoughts/comments.
Split packages are sometimes forced upon us. For example, the
transactions APIs are partially provided by the JDK. This might be a
case for using Require-Bundle, but then there are also other
techniques to avoid resolving t
Guillaume Nodet wrote:
For those that are not aware of ServiceMix Kernel (I know David is),
i'd like to point them to it. Feel free to download it and give it a
try. It's based on felix, gshell and a few other bundles. We're using
it to deploy our JBI container in ServiceMix 4 (including the
Hi Gianny,
On Mar 17, 2009, at 4:24 AM, Gianny Damour wrote:
On 13/03/2009, at 6:44 PM, David Jencks wrote:
On Mar 12, 2009, at 10:02 AM, David Jencks wrote:
On Mar 12, 2009, at 3:25 AM, Gianny Damour wrote:
On 12/03/2009, at 4:29 AM, David Jencks wrote:
I think I probably have the mo
On 07/04/2009, at 4:00 AM, David Jencks wrote:
There are two things that worry me about this.
1. IIUC whenever you include a jar in a configuration all the
configuration's parents get added as parents to the jar's global
classloader, in this code in MultiParentClassLoader2:
protected
On Apr 7, 2009, at 1:46 AM, Gianny Damour wrote:
On 07/04/2009, at 4:00 AM, David Jencks wrote:
There are two things that worry me about this.
1. IIUC whenever you include a jar in a configuration all the
configuration's parents get added as parents to the jar's global
classloader, in t
On 08/04/2009, at 5:10 PM, David Jencks wrote:
On Apr 7, 2009, at 1:46 AM, Gianny Damour wrote:
On 07/04/2009, at 4:00 AM, David Jencks wrote:
There are two things that worry me about this.
1. IIUC whenever you include a jar in a configuration all the
configuration's parents get added a
On Apr 8, 2009, at 6:09 AM, Gianny Damour wrote:
On 08/04/2009, at 5:10 PM, David Jencks wrote:
On Apr 7, 2009, at 1:46 AM, Gianny Damour wrote:
On 07/04/2009, at 4:00 AM, David Jencks wrote:
There are two things that worry me about this.
1. IIUC whenever you include a jar in a configu
49 matches
Mail list logo
