You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by jw...@21technologies.com on 2006/07/07 22:58:01 UTC
Re: Dynamically creating datasources
*bump*
I don't mind doing some more legwork, but I could really use a nudge in
the right direction. Aaron mentioned that I could use the console code as
a template for what I'm doing. Can someone point me at the right place to
look in the source tree? I did a little bit of poking around, but I got a
bit lost trying to figure out which module to begin searching.
--
Jimmy Wan
Senior Technical Lead
21st Century Technologies, Inc.
4515 Seton Center Parkway Suite 320
Austin, TX 78759
Phone: 512-342-0010 x249
Email: jwan@21technologies.com
URL: http://www.21technologies.com
The information in this email and in any attachments is confidential and
may be privileged. If you are not the intended recipient, please destroy
this message, delete any copies held on your systems and notify the sender
immediately. You should not retain, copy or use this email for any
purpose, nor disclose all or any part of its content to any other person.
jwan@21technologies.com wrote on 06/29/2006 12:14:59:
> I gave this some more thought. I guess it doesn't matter if the
> datasources are actually persisted or not. In theory, I could remove
> or update & redeploy all non-bootstrap datasources on startup,
> correct? Can you point me at how to programmatically
> add/remove/inspect datasources via a standard Geronimo deployment?
> The key constraint is to avoid doing it through the UI and/or having
> it be a manual deployment step.
>
> P.S. Thanks to the other suggestions, but I don't want to use Spring
> at this time.
>
> --
> Jimmy Wan
>
> Aaron Mulder wrote:
> You can use a similar path to what the console does to create new
> datasources. That is to select a matching RAR (the tranql-connector
> RAR for almost any non-XA data source) and then use JSR-88 to
> construct a JavaBean tree representing the deployment plan, and then
> more JSR-88 to actually deploy it.
>
> However, this is going to create a regular Geronimo deployment. When
> you say you don't want this to be persisted, you mean you want it to
> be in-memory only and not started up again the next time the server
> starts? We don't have explicit support for running modules that are
> in-memory only... I'm not sure what you could do to get around that.
>
> Thanks,
> Aaron
>
> On 6/25/06, Jimmy Wan <jw...@21technologies.com> wrote:
> I'm trying to build an application where one of the necessary operations
> is the run-time creation of new datasources.
>
> The general idea is that on startup, there will be a single datasource
> registered with Geronimo, containing references to the database
> containing connection information for other databases. If/when new
> databases are registered in the application, the datasources would be
> dynamically added using the connection info that was placed into the
> startup database. The startup database would be the single point of
> configuration for this information. I do want connections to these other
> databases to be managed by Geronimo, but I don't want to manually add
> these connections to Geronimo. I also don't want this configuration
> information to be persisted.
>
> I did something similar with JBoss, but it was a while ago and the
> details are now a tad fuzzy on exactly how this was accomplished.
>
> I could use a nudge in the right direction. What's the best way to do
> this in Geronimo?
>
> --
> Jimmy Wan
Re: Dynamically creating datasources
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I guess the question is how the application will access the dynamic
data sources.
It would be possible to have a Factory GBean with an interface like this:
public interface DataSourceFactory {
public DataSource getDataSource(String name);
}
Then the GBean implementing that interface could connect to the
metadata data source during startup, and use code like David outlined
below to create a ManagedConnectionFactoryWrapper for each data source
defined in the metadata database and associate each one with some name
that callers will use to look it up.
So then the application components could use a gbean-ref with type
DataSourceFactory to put the DataSourceFactory in their JNDI space,
and use code like this to look up a specific connection:
Context ctx = new InitialContext();
DataSourceFactory factory =
(DataSourceFactory)ctx.lookup("java:comp/env/DataSources");
DataSource ds = factory.getDataSource("TheDataSourceIWant");
Connection con = ds.getConnection();
...
However, that puts the factory in JNDI, not the created data source
itself, so the code looks a little different than it would if the code
was using a statically configured data source.
I'm not sure of a reasonable way for application components to map
data sources into their JNDI space if the data sources don't exist
until the factory GBean is started, and in particular, if the data
sources aren't themselves proper GBeans.
It would help if we had the concept of runtime-only GBeans -- that is,
GBeans that were added to a module during startup and removed during
shutdown and never persisted. But we don't have explicit handling for
that kind of thing right now -- we normally assume that if you create
a GBean then you mean to keep it around.
Thanks,
Aaron
On 7/7/06, David Jencks <da...@yahoo.com> wrote:
>
>
>
> On Jul 7, 2006, at 1:58 PM, jwan@21technologies.com wrote:
>
> *bump*
>
> I don't mind doing some more legwork, but I could really use a nudge in the
> right direction. Aaron mentioned that I could use the console code as a
> template for what I'm doing. Can someone point me at the right place to look
> in the source tree? I did a little bit of poking around, but I got a bit
> lost trying to figure out which module to begin searching.
>
> I think we already discussed that you are not going to be able to look up
> these datasources from jndi, so you'll have to provide your own access
> method.
>
> I think what I would do is simply construct instances of the objects you
> need in code, and not even use gbeans for them at all. Something like:
>
> TransactionSupport transactionSupport = new XATransactions(.... figure out
> what you want ...);
> PoolingSupport poolingSupport = new SinglePool(... likewise);
> ConnectionTracker connectionTracker = //look this up in the kernel or if
> this code is in a gbean use a reference
> TransactionContextManager transactionContextManager = //likewise
>
> GenericConnectionManager cm = new
> GenericConnectionManager(transactionSupport,
> poolingSupport,
> true,
> connectionTracker,
> transactionContextManager,
> name,
> classLoader);
>
> cm.doStart();//this doesn't actually do anything, but you should shut it
> down when you are done.
>
> ManagedConnectionFactoryWrapper mcfw = new
> ManagedConnectionFactoryWrapper(mcfClass,
> DataSource.class.getName(),
> new String[] {},
> datasourceImplClass, //this would be the tranql adapter datasource
> class if you are using tranql. You can get it from the ra.xml
> Connection.class.getName(),
> null,
> cm,
> kernel,
> abstractName, /I don't think this is needed if you don't serialize
> datasources.
> objectName, //I don't think this is needed.
> classLoader);
>
> mcfw.doStart();
>
> DataSource ds = (DataSource) mcfw.$getResource();
>
>
> Hope this gives you some ideas on one possible way forward,
>
> david jencks
>
>
> --
> Jimmy Wan
> Senior Technical Lead
> 21st Century Technologies, Inc.
> 4515 Seton Center Parkway Suite 320
> Austin, TX 78759
>
> Phone: 512-342-0010 x249
> Email: jwan@21technologies.com
> URL: http://www.21technologies.com
>
> The information in this email and in any attachments is confidential and may
> be privileged. If you are not the intended recipient, please destroy this
> message, delete any copies held on your systems and notify the sender
> immediately. You should not retain, copy or use this email for any purpose,
> nor disclose all or any part of its content to any other person.
>
>
> jwan@21technologies.com wrote on 06/29/2006 12:14:59:
> > I gave this some more thought. I guess it doesn't matter if the
> > datasources are actually persisted or not. In theory, I could remove
> > or update & redeploy all non-bootstrap datasources on startup,
> > correct? Can you point me at how to programmatically
> > add/remove/inspect datasources via a standard Geronimo deployment?
> > The key constraint is to avoid doing it through the UI and/or having
> > it be a manual deployment step.
> >
> > P.S. Thanks to the other suggestions, but I don't want to use Spring
> > at this time.
> >
> > --
> > Jimmy Wan
> >
> > Aaron Mulder wrote:
> > You can use a similar path to what the console does to create new
> > datasources. That is to select a matching RAR (the tranql-connector
> > RAR for almost any non-XA data source) and then use JSR-88 to
> > construct a JavaBean tree representing the deployment plan, and then
> > more JSR-88 to actually deploy it.
> >
> > However, this is going to create a regular Geronimo deployment. When
> > you say you don't want this to be persisted, you mean you want it to
> > be in-memory only and not started up again the next time the server
> > starts? We don't have explicit support for running modules that are
> > in-memory only... I'm not sure what you could do to get around that.
> >
> > Thanks,
> > Aaron
> >
> > On 6/25/06, Jimmy Wan <jw...@21technologies.com> wrote:
> > I'm trying to build an application where one of the necessary operations
> > is the run-time creation of new datasources.
> >
> > The general idea is that on startup, there will be a single datasource
> > registered with Geronimo, containing references to the database
> > containing connection information for other databases. If/when new
> > databases are registered in the application, the datasources would be
> > dynamically added using the connection info that was placed into the
> > startup database. The startup database would be the single point of
> > configuration for this information. I do want connections to these other
> > databases to be managed by Geronimo, but I don't want to manually add
> > these connections to Geronimo. I also don't want this configuration
> > information to be persisted.
> >
> > I did something similar with JBoss, but it was a while ago and the
> > details are now a tad fuzzy on exactly how this was accomplished.
> >
> > I could use a nudge in the right direction. What's the best way to do
> > this in Geronimo?
> >
> > --
> > Jimmy Wan
>
Re: Dynamically creating datasources
Posted by David Jencks <da...@yahoo.com>.
On Jul 7, 2006, at 1:58 PM, jwan@21technologies.com wrote:
>
> *bump*
>
> I don't mind doing some more legwork, but I could really use a
> nudge in the right direction. Aaron mentioned that I could use the
> console code as a template for what I'm doing. Can someone point me
> at the right place to look in the source tree? I did a little bit
> of poking around, but I got a bit lost trying to figure out which
> module to begin searching.
I think we already discussed that you are not going to be able to
look up these datasources from jndi, so you'll have to provide your
own access method.
I think what I would do is simply construct instances of the objects
you need in code, and not even use gbeans for them at all.
Something like:
TransactionSupport transactionSupport = new XATransactions(....
figure out what you want ...);
PoolingSupport poolingSupport = new SinglePool(... likewise);
ConnectionTracker connectionTracker = //look this up in the kernel or
if this code is in a gbean use a reference
TransactionContextManager transactionContextManager = //likewise
GenericConnectionManager cm = new GenericConnectionManager
(transactionSupport,
poolingSupport,
true,
connectionTracker,
transactionContextManager,
name,
classLoader);
cm.doStart();//this doesn't actually do anything, but you should shut
it down when you are done.
ManagedConnectionFactoryWrapper mcfw = new
ManagedConnectionFactoryWrapper(mcfClass,
DataSource.class.getName(),
new String[] {},
datasourceImplClass, //this would be the tranql adapter
datasource class if you are using tranql. You can get it from the
ra.xml
Connection.class.getName(),
null,
cm,
kernel,
abstractName, /I don't think this is needed if you don't
serialize datasources.
objectName, //I don't think this is needed.
classLoader);
mcfw.doStart();
DataSource ds = (DataSource) mcfw.$getResource();
Hope this gives you some ideas on one possible way forward,
david jencks
>
> --
> Jimmy Wan
> Senior Technical Lead
> 21st Century Technologies, Inc.
> 4515 Seton Center Parkway Suite 320
> Austin, TX 78759
>
> Phone: 512-342-0010 x249
> Email: jwan@21technologies.com
> URL: http://www.21technologies.com
> The information in this email and in any attachments is
> confidential and may be privileged. If you are not the intended
> recipient, please destroy this message, delete any copies held on
> your systems and notify the sender immediately. You should not
> retain, copy or use this email for any purpose, nor disclose all or
> any part of its content to any other person.
>
>
> jwan@21technologies.com wrote on 06/29/2006 12:14:59:
> > I gave this some more thought. I guess it doesn't matter if the
> > datasources are actually persisted or not. In theory, I could remove
> > or update & redeploy all non-bootstrap datasources on startup,
> > correct? Can you point me at how to programmatically
> > add/remove/inspect datasources via a standard Geronimo deployment?
> > The key constraint is to avoid doing it through the UI and/or having
> > it be a manual deployment step.
> >
> > P.S. Thanks to the other suggestions, but I don't want to use Spring
> > at this time.
> >
> > --
> > Jimmy Wan
> >
> > Aaron Mulder wrote:
> > You can use a similar path to what the console does to create new
> > datasources. That is to select a matching RAR (the tranql-connector
> > RAR for almost any non-XA data source) and then use JSR-88 to
> > construct a JavaBean tree representing the deployment plan, and then
> > more JSR-88 to actually deploy it.
> >
> > However, this is going to create a regular Geronimo deployment.
> When
> > you say you don't want this to be persisted, you mean you want it to
> > be in-memory only and not started up again the next time the server
> > starts? We don't have explicit support for running modules that are
> > in-memory only... I'm not sure what you could do to get around
> that.
> >
> > Thanks,
> > Aaron
> >
> > On 6/25/06, Jimmy Wan <jw...@21technologies.com> wrote:
> > I'm trying to build an application where one of the necessary
> operations
> > is the run-time creation of new datasources.
> >
> > The general idea is that on startup, there will be a single
> datasource
> > registered with Geronimo, containing references to the database
> > containing connection information for other databases. If/when new
> > databases are registered in the application, the datasources
> would be
> > dynamically added using the connection info that was placed into the
> > startup database. The startup database would be the single point of
> > configuration for this information. I do want connections to
> these other
> > databases to be managed by Geronimo, but I don't want to manually
> add
> > these connections to Geronimo. I also don't want this configuration
> > information to be persisted.
> >
> > I did something similar with JBoss, but it was a while ago and the
> > details are now a tad fuzzy on exactly how this was accomplished.
> >
> > I could use a nudge in the right direction. What's the best way
> to do
> > this in Geronimo?
> >
> > --
> > Jimmy Wan