[moving this discussion from the private TCK list since it has
entered a subject that is not private]
On Apr 17, 2006, at 4:47 PM, Aaron Mulder wrote:
On 4/17/06, David Jencks <[EMAIL PROTECTED]> wrote:
Maybe you mixed up some version numbers here?
I did mean "make it work like 1.0 again". Sigh.
In any case, in 1.1 it isn't possible to specify the whole abstract
name, so on that count your worries are over :-)
Oh. That's quite nice. :)
However, I don't see any reasonable way to deduce exactly which
configuration you intended to use, and I think its a good idea to
link up the configurations in use explicitly: among other effects
this makes extracting a complete working server possible.
Well, for starters, I agree that it would be ideal if you explicitly
list all your dependencies. We can definitely advise that.
I'd like to make it as forgiving as possible though, and even listing
dependencies doesn't prevent you from including two configurations as
parents that both have a component with the name in question. Perhaps
something like:
1) Search from current configuration up through parents. Return the
first (leaf-most) match. If two parents at the same level both have a
match, raise an error.
2) If no matches are found in the parent hierarchy, search all
top-level deployments. If one match is found there, return it. If
zero or multiple matches are found, raise an error.
What do you think?
Thanks,
Aaron
Exactly, what I was thinking. I also think this should happen during
deployment. If the specified resource can't be found in a parent
search all configurations for that resource. If we find one exact
match, we should mark the configuration containing that resource as a
dependency. A problem I now see, is it may be prohibitively
expensive to search all configurations, since using today's
technology it means loading an deserializing every configuration in
the repository.... I believe we can do that in 1.2, with the move
away from serialized configurations to a recipe model.
-dain
[more history in this thread follows...]
On Apr 17, 2006, at 3:54 PM, David Jencks wrote:
On Apr 17, 2006, at 3:37 PM, Aaron Mulder wrote:
I think the issue is this (if I understand David J correctly):
- You declare a JMS connection factory in a JMS configuration and
deploy that in the server (or do it in the console and the console
deploys it for you)
- In 1.0, you can deploy an application with a JMS resource
reference
of type javax.jms.ConnectionFactory, and in your Geronimo plan use a
resource-link with the "name" of the connection factory (the simple
name used for that component, not a full ObjectName or AbstractName),
and you're good to go (it searches the application for a resource of
that name, and then not finding one, searches all top-level
deployments in the server and find the connection factory in the JMS
configuration)
- In 1.1, you do the same thing and it doesn't work, because the
resource-link search only looks in your direct parent configurations
(j2ee-server, j2ee-system, rmi-naming, ...) and never sees the JMS
configuration. (Unless you explicitly list it as a dependency, so
it's in your parent path.)
If that's right, I'd really be in favor of finding a way to make it
work like 1.1 again. The *last* thing I want to see is more mapping
that requires a full ObjectName or AbstractName (motto: You'll get it
wrong on the first try, and I'll be explaining how you need to
look up
the right value up in the JMX Debug tool and paste it into your plan.
Trust me on this.) It will certainly be possible (preferable) to
encourage people to list the JMS/JDBC/Security configurations as
dependencies of their applications, but I think it would clearly be
best not to require that if we can avoid it.
Maybe you mixed up some version numbers here?
In any case, in 1.1 it isn't possible to specify the whole abstract
name, so on that count your worries are over :-)
However, I don't see any reasonable way to deduce exactly which
configuration you intended to use, and I think its a good idea to
link up the configurations in use explicitly: among other effects
this makes extracting a complete working server possible.
thanks
david jencks
Thanks,
Aaron
On 4/17/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
I don't know what the answer to any of these are, but I think JMS
should be as easy to use as it is on any other app server. IIRC, on
most app servers you just declare some JNDI refs and add some MDBs
and it just works. Of course a serious user should tune setup for
their actual use case, but you should be able to get an example
working in 10 minutes.
Is that how Geronimo works?
-dain
On Apr 17, 2006, at 10:57 AM, David Jencks wrote:
On Apr 17, 2006, at 10:43 AM, Dain Sundstrom wrote:
On Apr 16, 2006, at 10:57 PM, David Jencks wrote:
Most of the test failures have been caused by a difference in
gbean search. Previously resource-links were looked for in any
standalone module. Now they are looked for in any ancestor
configuration of the one doing the looking. As a result, the jms
and database configurations must be dependencies of any j2ee app
that uses the tck database or jms setup. I've added both to the
earConfigBuilder defaultEnvironment.
Are we going to add JMS as a default dependency in main Geronimo,
This would be really bad IMO, who really wants to use our lame
example jms setup?
or are we going to have the builder detect that the application is
using JMS and add the dependency?
This is equally bad for the same reason. Right now I don't see any
plausible way to automate guessing what other configurations a
particular configuration depends on, do you have an idea? This
guessing needs to be done by the packaging plugin, so it has the
entire local or possibly ibiblio maven repo to consider...
thanks
david jencks
-dain
