I just came across a similar problem that would be solved by this.
I currently have a database configuration and an application
configuration. The database isn't directly in the dependency hierarchy
for the application, but I passed it first on the command line and it
worked OK: "java -jar bin/server.jar DB app"
The problem is that if I then run the server with no arguments,
the app fails to start on account of the database not being ready. Both
entries were present in the var/config/config.list, so I assume it just
started them out of order when I didn't maually provide the ordering on
the command line.
If it's going to be a long-term fix to implement the dependency
strategy outlined in this thread, it may be worth putting in a quicker fix
to preserve component ordering when writing to and reading from the
var/config/config.list file.
Aaron
On Sun, 3 Oct 2004, David Jencks wrote:
> I agree, this is a good idea. Lets have the default value for the flag
> be "mandatory", i.e you only include the flag when it is optional. We
> can presumably do the same with ejb-refs from web apps to ejbs? I
> don't think we can have dependencies between ejbs since there can be
> circular references.
>
> david jencks
> On Oct 3, 2004, at 12:26 PM, Jeremy Boynes wrote:
>
> > toby cabot wrote:
> >> On a (hopefully) related topic, what's the mechanism to declare the
> >> dependencies within an ear? I ask because I've got a webapp that uses
> >> a connector and despite a <resource-ref> in web.xml and a
> >> <resource-ref> in geronimo-jetty.xml I get
> >> javax.naming.NamingException: could not look up : env/ra/CF [Root
> >> exception is java.lang.IllegalStateException: Proxy not returned.
> >> Target
> >> geronimo.server:
> >> J2EEServer=geronimo,j2eeType=JCAManagedConnectionFactory,name=testCF
> >> not started] when I start the server. I assumed that the
> >> <resource-ref> provided
> >> the dependency data to the server, but if there's some other technique
> >> I need to use I'll try that.
> >
> > I think this is a reasonable assumption - it certainly makes sense
> > from the application's viewpoint.
> >
> > I should not be that hard to do - after all at deployment time we know
> > all the references a component is making and what they will ultimately
> > resolve to. Seeing as any attempt to use the resource will fail, then
> > we might as well not start the component.
> >
> > The big downside I see is that it means a component won't start unless
> > all its local references can be resolved. This could be an issue if
> > there is logic in the code that chooses between references based on
> > application-level criteria. Perhaps we should add a flag to the
> > resource-ref that tags it as mandatory (we create a dependency) or
> > optional (we don't).
> >
> > --
> > Jeremy
> >
>
>
