-
1. Re: JBINSTALL-49, DataSource configuration
sebersole Jun 1, 2006 10:14 AM (in response to starksm64)I think I am missing some context or discussion behind this...
1) So the overall feature being requested is the ability to specify the database to be used by default in JBAS install performed through the installer? If the list of available database to choose from here is finite, could you not just plugin in wizards based on the db selected to walk through additonal config? Sorry, not really sure how the installer works overall...
2) DDL for what exactly? -
2. Re: JBINSTALL-49, DataSource configuration
jimm Jun 1, 2006 10:54 AM (in response to starksm64)>2) DDL for what exactly?
deploy/jms/hsqldb-jdbc-state-service.xml
deploy/jms/hsqldb-jdbc2-service.xml
deploy/uuid-key-generator.sar/META-INF/jboss-service.xml -
3. Re: JBINSTALL-49, DataSource configuration
sebersole Jun 1, 2006 12:00 PM (in response to starksm64)The JMS stuff is easy enough; we'll just need to provide the appropriate Hibernate metadata. I assume the JDBC types are consistent between the different databases schemas?
I would need someone to explain to me in more detail the purpose of the two services in the key generator deployment in terms of what they expect in the database. Or point me to the appropriate src location for the source code. -
4. Re: JBINSTALL-49, DataSource configuration
jimm Jun 1, 2006 1:22 PM (in response to starksm64)See http://fisheye.jboss.com/viewrep/JBoss/jboss/src/main/org/jboss/ejb/plugins/keygenerator/hilo/HiLoKeyGenerator.java
The ddl is only used for the HiLoKeyGenerator Service.
The service is just a utility for getting unique ids. There are no AS dependencies on this service. Maybe it should just be reimplemented with Hibernate generators? -
5. Re: JBINSTALL-49, DataSource configuration
jimm Jun 1, 2006 1:25 PM (in response to starksm64)Also, I don't know what has to be done for the new Messaging stuff.
-
6. Re: JBINSTALL-49, DataSource configuration
alex.pinkin Jun 1, 2006 5:46 PM (in response to starksm64)1) Installer currently doesn't allow to configure datasource. I agree that we should stick with just configuring DefaultDS for now. It would be nice to keep it simple though and avoid creating DB-specific configuration panels. Why don't we just allow user to select DB type, enter connection-url, username and password, as well as XA flag? Customers can update other DS parameters after the install by hand.
As far as including 3rd party JDBC drivers, we should probably do it for the most popular OS databases. -
7. Re: JBINSTALL-49, DataSource configuration
amit.bhayani Jun 28, 2006 1:30 PM (in response to starksm64)I was thinking on how Installer can make life easy by featuring the custom datasource configuration. Instead of having a hsqldb-ds Pack, I was thinking on having a config-datasource pack and a UserInput Panel which will ask user to enter
DataSource JNDI Name
Local or XA
Connection URL
driver-class
user-name
password
etc etc fields of ds
and having a vm template to create a full fledge *-ds.xml file.
I can use the JNDI name entered by user to be replaced in *-service.xml files used for JMS. Also to have exploded uuid-key-generator.sar so that I can easily replace the Datasource JNDI name in jboss-service.xml
This will give us atleast the start but there are few gray areas like
1) How do I force user to add the driver .jar files? May be I can just have a TODO and note to user to copy it manually
2) For different database we have different DDL in PersistenceManager for JMS and other files. How do I select the appropriate one depending on what database user is using?
Scott can you please elaborate on how we can make use of Hibernate here? -
8. Re: JBINSTALL-49, DataSource configuration
sebersole Jun 28, 2006 1:39 PM (in response to starksm64)The thought was to no longer maintain such DDL scripts, but to use Hibernate to generate the DDL in the database-independent way that it does.
-
9. Re: JBINSTALL-49, DataSource configuration
alex.pinkin Jun 28, 2006 2:01 PM (in response to starksm64)(1): imho it's ok to just notify user that JDBC driver needs to be copied manually to /server/default/lib. Later we can implement a custom panel which allows user to select a JDBC driver and then copies it over.
As far as exposing datasource type specific parameters in the installer, I would postpone this. First we should implement common parameters like connection-url, name, password, xa.