Matt Raible wrote:
On 5/14/07, Dave <[EMAIL PROTECTED]> wrote:
On 5/14/07, Matt Raible <[EMAIL PROTECTED]> wrote:
> On 5/14/07, Dave <[EMAIL PROTECTED]> wrote:
> > On 5/14/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
> > > Dave wrote:
> > > > On 5/14/07, Anil Gangolli <[EMAIL PROTECTED]> wrote:
> > > >> I'm in favor of an installer but I'd suggest keeping it
separate from the
> > > >> webapp itself; I may not be grasping the rationale for
putting it in the
> > > >> webapp.
> > > >
> > > > I'm still looking at options, but it seems the easiest
situation for
> > > > the user would be a single WAR file that knows how to create
> > > > resources, create/upgrade tables and configure itself -- just as
> > > > Wordpress does. I'm not sure that is technically possible or
feasible
> > > > given the fact that we want to support multiple app servers.
I'm also
> > > > looking at the idea of a separate installer to at least do the
> > > > resource creation.
> > >
> > > We should probably expand the scope of this discussion a bit
then and
> > > think about it more along the lines of 'ease of installation'
improvements.
> >
> > Yes. I hope to have a installer proposal ready by the end of the
week.
> >
> >
> > > I agree that having the app be able to manage the database
itself is
> > > pretty nice and i don't see any reason why we can't do something
like
> > > that, but since many folks do use Roller as an enterprise app I
think
> > > we'll definitely want to make it easy to disable that so that the
> > > scripts can be run manually.
> >
> > Definitely, we want users to be able to override auto-installation.
> >
> >
> > > As far as an external installer is concerned, I can see that as
being a
> > > nice thing if it's done well, but IMO that should not be
necessary. I
> > > think that the way to make the app as easy to install as
possible is to
> > > be able to simply drop it in a web container and define any
> > > configuration necessary either after it's been deployed, or before
> > > deployment using our config file, and that's it.
> >
> > > I actually think this
> > > should include the database and mail resources as well, since
trying to
> > > maintain docs and info about how to do that across XX app
servers is
> > > difficult and effectively unnecessary. We should be able to
provide our
> > > own way of managing those resources so that we can make it easy and
> > > standard for users to configure.
> >
> > Managing our own configuration does have some advantages. I think it
> > should be part of the picture, but I also need to be able to handle
> > the case where we use the "container managed" database pools, mail
> > sessions and authentication that are built into the various
> > application servers.
>
> This is pretty easy to do with Spring. ;-)
Which parts? Spring will automatically create the JDNI database
resources and mail-session that web need on Glassfish, Tomcat, JBoss
etc.?
I won't create them, but it will allow you to configure a MailSession
and DataSource (connection pool) as a bean definition, or as a JNDI
Resource. For example, you can have it configured in the application
using the following bean definition:
<bean id="dataSource"
class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
<property name="driverClassName" value="${jdbc.driverClassName}"/>
<property name="url" value="${jdbc.url}"/>
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
<property name="maxActive" value="100"/>
<property name="maxIdle" value="30"/>
<property name="maxWait" value="1000"/>
<property name="defaultAutoCommit" value="true"/>
<property name="removeAbandoned" value="true"/>
<property name="removeAbandonedTimeout" value="60"/>
</bean>
The problem with this is that it doesn't actually buy us anything. We
don't actually want our users having to edit the spring config in the
webapp so there is no real benefit in doing this.
-- Allen
Or you can look it up from JNDI:
<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/roller"/>
As far as the application is concerned, both are DataSource types and
it shouldn't really care where they come from.
The new annotation-based stuff in 2.1 might allow us to configure a
DataSource dependency with an annotation.
http://tinyurl.com/2zx66s
With annotations, the backend wouldn't need to be wired with Spring,
you could just inject where you need to. Of course, we could probably
use Google Guice to do the same thing.
Matt
