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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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 david_jen...@yahoo.com wrote:
I read the blog entry and discussion. The entire discussion is
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
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
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
@geronimo.apache.org
Sent: Thursday, 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
of comparing
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.
See comments below.
Lin
On Thu, Mar 12, 2009 at 1:51 AM, Jarek Gawor jga...@gmail.com 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
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,
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
On Wed, Mar 11, 2009 at 08:57, Gianny Damour
gianny.dam...@optusnet.com.auwrote:
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
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
Guillaume Nodet wrote:
On Wed, Mar 11, 2009 at 08:57, Gianny Damour
gianny.dam...@optusnet.com.au 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
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 that
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 Wed, Mar 11, 2009 at 1:29 PM, David Jencks david_jen...@yahoo.com 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
On Mar 11, 2009, at 11:27 AM, Jarek Gawor wrote:
On Wed, Mar 11, 2009 at 1:29 PM, David Jencks
david_jen...@yahoo.com 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
On Wed, Mar 11, 2009 at 20:30, David Jencks david_jen...@yahoo.com wrote:
On Mar 11, 2009, at 11:27 AM, Jarek Gawor wrote:
On Wed, Mar 11, 2009 at 1:29 PM, David Jencks david_jen...@yahoo.com
wrote:
On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote:
Hi,
So let's agree to disagree for
On Wed, Mar 11, 2009 at 3:30 PM, David Jencks david_jen...@yahoo.com 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
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
://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
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.html
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
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
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 david_jen...@yahoo.com wrote:
Geronimo has been around for a while and despite the many good features
gbeans and the geronimo kernel are not catching on big
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
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
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 xhh...@gmail.com
It
48 matches
Mail list logo
