geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Start-up classes
Date Wed, 23 Nov 2005 21:03:45 GMT
I think I am going to try solution 1. It sounds promising and it's easy
for other people to understand.

Regarding this:

> There is probably no guarantee that a user call to an ejb will be 
delayed until after your gbean  is started

I think you are saying that deploying is not an atomic operation
as far as new transactions are concerned. I think that could be a problem
for people who have hundreds of transactions waiting for an application to
be deployed/redeployed.

I'll try solution 2 if 1 doesn't work out.

Solution 3 is not an option for now. 

Solution 4 I like best, but since the business is not mine I usually 
that I am required to be selfish and do the least amount of work I can, 
and there
is the usual matter of somebody reviewing the IP to make sure they don't 
giving it away. However, if the migration starts looking good then I will 
the issue to a couple of executives here to see if they are okay with the 
idea of
submitting patches. If they are, I can start being a good citizen.

David Jencks <>
11/23/2005 12:29 PM
Please respond to user

        Subject:        Re: Start-up classes

On Nov 23, 2005, at 12:14 PM, wrote:

> We have a whole list of classes whose static initialization needs to 
> happen in
> a specific order. If a thread tries to use any one of them before the 
> class initialization
> is completed, it can cause deadlocks, which will stop the application 
> from starting.
> I don't code like this myself, but I inherited this, and my focus here 
> is to get this deployed
> on Geronimo the fastest way possible. It's about money.
> I was thinking that your kernel already has a concept of dependencies, 
> and it does have
> to figure out the graph of gbeans so that if A references B that 
> start() is called on B before
> it's called on A.
> So maybe I can create two gbeans: one is the one that does the 
> initialization (B), and the other
> is just empty and references it (A) and is part of the j2ee app 
> configuration? Then B should
> get initialized before A?
> Guglielmo

hmmm.  I can think of 3 things to try:

1. Include a gbean in the application that calls the startup code.  See 
if it works :-)  There is probably no guarantee that a user call to an 
ejb will be delayed until after your gbean  is started, but perhaps you 
can control that another way.  I would try this anyway to see what 
happens since it is the easiest solution.

2.  Move all of the relevant classes and the startup gbean into another 
configuration and make this configuration a parent (using the "import" 
tag which might change to "parent" in the next few days).  This will 
pretty much guarantee that your startup code is run before any ejb 
containers are deployed.  Your ejb app would then not include these 
classes, since they are in a parent classloader.  You will have to 
think about exactly what can be moved into a parent classloader and 
whether this will work.

3.  Make the startup code self-executing :-)  (I don't know if this 
will work)  Move the actual startup code in each of these classes into 
a static method, and have the static block just call the initializer 
class.  The initializer class would need some well-protected flag so 
the code was only run once, but it would call the static methods in 
each class in the appropriate order.

4. Push on us or submit a patch for all the gbeans we generate from 
j2ee apps to include the ability to specify dependencies.  This would 
be ideal.  Even for ejbs would be great and might not be a lot of work.

david jencks


In compliance with applicable rules and regulations, Instinet
reviews and archives incoming and outgoing email communications,
copies of which may be produced at the request of regulators.
This message is intended only for the personal and confidential
use of the recipients named above.  If the reader of this email
is not the intended recipient, you have received this email in
error and any review, dissemination, distribution or copying is
strictly prohibited. If you have received this email in error,
please notify the sender immediately by return email and
permanently delete the copy you received.  

Instinet accepts no liability for any content contained in the
email, or any errors or omissions arising as a result of email
transmission. Any opinions contained in this email constitute
the sender's best judgment at this time and are subject to change
without notice.   Instinet does not make recommendations of a
particular security and the information contained in this email
should not be considered as a recommendation, an offer or a
solicitation of an offer to buy and sell securities.


View raw message