dev@glassfish.java.net

Re: Resource Autodeployment

From: Jagadish Prasath Ramu <Jagadish.Ramu_at_Sun.COM>
Date: Fri, 06 Jun 2008 19:24:47 +0530

On Thu, 2008-06-05 at 13:22 -0500, Jason Lee wrote:
> On Wed, Jun 4, 2008 at 12:00 PM, Jagadish Prasath Ramu
> <Jagadish.Ramu_at_sun.com> wrote:
> We do not have a generic resources backend support. They have
> been
> individual deployers eg: Jdbc resource deployer, connector
> resource
> deployer, jndi resource deployer etc., and we would expect
> these
> resources to be owned by corresponding modules.
> eg: connector-resource, connector-connection-pool
> implemented/supported
> by connector module.
>
> Hmm. Perhaps my understanding of things isn't quite complete/correct.
> It seems to me that a JDBC resource and a JNDI resource are pretty
> closely related (in OO-ish terms, a JDBC resource isa JNDI resource),
> but it sounds like these are currently split out in different modules.
> Am I reading that incorrectly? If I'm not, it would seem like a
> deployer I've proposed would be difficult to implement cleanly.

Yes, we would expect that the resources to be available in corresponding
modules. But there may be generic code for resources, which we haven't
started investigating.

In v2, there will be commands to create various resources. These are
taken care by admin (administration) modules
Once the resource is created, backend will receive the events. Based on
the type of event and type of resource, appropriate resource-deployer
will be invoked.

In v3, same event listening mechanism will be there, but it will be in a
modularized fashion.
eg: There will be connector-resource,pool creation logic within
connectors/admin
and backend related code within connectors/connectors-runtime.

If you can send a proposal on what you intend to do (type of resources
that you plan to introduce, their functionality etc.,), that would be
helpful.

Please note that this is work in progress. So, we can plan according to
the new requirements.

Thanks,
-Jagadish

>
> --
> Jason Lee, SCJP
> Software Architect -- Objectstream, Inc.
> Mojarra and Mojarra Scales Dev Team
> https://mojarra.dev.java.net
> https://scales.dev.java.net
> http://blogs.steeplesoft.com