geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Resource resolution...
Date Tue, 18 Apr 2006 03:30:15 GMT
[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 <david_jencks@yahoo.com> 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 <dain@iq80.com> 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
>>>
>>>



Mime
View raw message