Johan Compagner wrote:
> > As I pointed out in a subsequent message on this thread ... you
> > need to avoid the use of the <data-sources> initialization service
> > if your container requires context attributes to be serializable.
> > In such cases, the app server will provide an alternative means
> > (JNDI InitialContext) to gain access to the data sources you need.
>
> Why depend on this?
Because it is the standard approach mandated for J2EE applications, to access
all sorts of resources (including data sources).
>
> Why not make the GenericDatabaseSource also serializeable with
> externalizeable?
>
I don't think just making it Externalizable (without also declaring
Serializable) will meet the requirements of the app servers. Does anyone know?
>
> then in the writeExternal(ObjectOutputStream) you close all the connections
> and save all the data (properties/maxcount/readOnly/ect/ect)
> when the readExternal is called you read all those properties and the
> connections will be created with the next call to getConnection()
>
You could do the same (with only slightly more pain) by creating custom
readObject() / writeObject() methods for serialization. I'd be willing to
accept a patch that does this -- I'm not going to have time to do it in the
short term.
However, there's a bigger issue here. The reason an app server wants to
serialize these things is to distribute them -- and there is no guarantee that
the database URL, username, password etc. are valid from every single server you
might distribute them to. You are also increasing the number of total
connections that will be established to your database -- perhaps without knowing
it -- even if the connection parameters are valid.
It seems to me that data sources belong to an individual server instance.
>
> I only don't know what to do with logWriter at this time the rest is easy to
> implement.
>
Same issue on PropertyMessageResourcesFactory ... I'm thinking on it.
>
> Johan
Craig
