On May 2, 2008, at 7:40 AM, Hernan Cunico wrote:
David Jencks wrote:
On Apr 30, 2008, at 2:14 PM, Hernan Cunico wrote:
Hi all,
When creating a connection pool and naming it in this from "jdbc/
something", the connection pool get created correctly.
When I check the available connectors however, this pool is listed
as "console.dbpool/jdbc%2Fsomething/1.0/rar". So, when I define a
dependency in a deployment plan I have to use "jdbc%2Fsomething"
instead of "jdbc/something"
I found 2 JIRAs (GERONIMO-2284 and GERONIMO-2314) mentioning the
"%2F".
Is there any chance (or limitation) to use "%2F" only for creating
the directories in the repo but having Geronimo to understand the
requirement for a "/" in the dep plans instead of a "%2F"?
This is leading to confusion as I am able to create a data source
with a "/" in the name but not able to use it when referencing to
the pool from a plan.
I'm pretty sure we encode artifact names as uris all over the place
so we'd have to move the encoding into the uri creating/parsing code.
I'd be more tempted to prohibit "/" from artifactIds.
Note that this issue is about the name of the module/plugin, NOT
the name of the datasource gbean, which is what is used in
persistence.xml and jndi resource-ref setup configuration. There
is no problem naming a datasource jdbc/foo
That's the thing, if there is no problem naming a datasource jdbc/
foo then
there should be no problem in referencing it.
As it is now, If I add a dependency to jdbc/foo in the dep plan it
will fail to deploy.
Not sure how we can get away naming a datasource jdbc/foo and not
slamming
a "/" in the artifactId though.
???
One is the datasource name, which ends up in a "name=jdbc/Foo" part of
the gbean name, the other is the moduleId which has "/" separated
components in the string or URI representation of the gbean name.
so if I try to name both jdbc/foo I'd end up with something like
org.foo/jdbc/foo/1.0/car?name=jdbc/
foo,j2eeType=JCAManagedConnectionFactory,....
As you can see the part before the ? won't parse into an artifact due
to the unescaped "/" in the artifactId component.
Assuming this module is an ancestor of my app, any resource-ref to
jdbc/foo will resolve to this datasource, no matter what the name of
the module.
hope this clarifies what is going on
david jencks
Cheers!
Hernan
thanks
david jencks
Cheers!
Hernan
