You can always use "tomee.pool.ageMax" or something like that.
I didn't understand your comment about resource management.
Romain Manni-Bucau wrote on 02/14/15 06:22:
>
> Ps: in tomee we use setters on pool as well so age-max wouldnt be supported
> and is opposed to the resource management we try to do
>
> Le 14 févr. 2015 13:31, "arjan tijms" <arjan.tijms_at_gmail.com
> <mailto:arjan.tijms_at_gmail.com>> a écrit :
>
> Hi,
>
> On Sat, Feb 14, 2015 at 11:27 AM, Romain Manni-Bucau
> <rmannibucau_at_gmail.com <mailto:rmannibucau_at_gmail.com>> wrote:
> > What is mandatory IMO to make it a bit portable is to standardize keys for
> > basic configs (min/max size, eviction..., and pool usage or not).
>
> Indeed, another step in making it a bit more portable is seeing what
> additional pool properties can be standardized for a next version.
> There's now a handful of them that were established years ago. I think
> it wouldn't hurt to at least take a look at whether we can expand this
> set.
>
> Kind regards,
> Arjan Tijms
>
>
>
> >
> > Le 14 févr. 2015 02:06, "Bill Shannon" <bill.shannon_at_oracle.com
> <mailto:bill.shannon_at_oracle.com>> a écrit :
> >
> >> arjan tijms wrote on 02/13/15 14:53:
> >> > Hi,
> >> >
> >> > On Fri, Feb 13, 2015 at 8:33 PM, Bill Shannon
> <bill.shannon_at_oracle.com <mailto:bill.shannon_at_oracle.com>>
> >> > wrote:
> >> >> Here's how we expected this to work...
> >> >>
> >> >> Any property that matches a JavaBeans property on the JDBC vendor's
> >> >> DataSource implementation would be set on an instance of that class.
> >> >> The rest of the properties, or maybe just all of the properties,
> >> >> would be passed to the connection pool implementation to configure
> >> >> the connection pool. Nothing other than the connection pool
> >> >> implementation
> >> >> needed to know which properties were for the connection pool.
> >> >>
> >> >> Is there a reason that won't work?
> >> >
> >> > The DataSource implementation is unknown in general. Suppose that my
> >> > custom one happens to have a property called "useStrictMin" and that
> >> > this just happens to be a property of the pool as well. In that case
> >> > how does the implementation know which property to set? Both?
> >> > DataSource? Pool? None? Throw exception?
> >>
> >> We would recommend that the connection pool properties not be of a form
> >> that could be confused with the JavaBeans properties on the DataSource,
> >> e.g., "org.glassfish.useStrictMin" or "use-strict-min".
> >>
> >> > Additionally, I wonder, is it really clear to vendors and users alike
> >> > that the general properties can now go to either the pool or the data
> >> > source?
> >>
> >> Presumably the users understand what the properties are doing and don't
> >> really need to understand how they're routed to the right component.
> >>
> >> > I know that IBM 100% gets this (see
> >> >
> >> >
> http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/cdat_datres.html?cp=SSAW57_8.5.5%2F1-3-0-23-3-0-0-3)
> >> > but it may be possible that e.g. JBoss just doesn't know this.
> >> >
> >> > See
> >> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.wildfly/wildfly-connector/8.2.0.Final/org/jboss/as/connector/deployers/datasource/DirectDataSourceInjectionSource.java#193
> >> >
> >> > From the source it's clear that JBoss compares all properties against
> >> > the configured DataSource class, and throws away everything that's not
> >> > a property of the DataSource. It doesn't even attempt to set anything
> >> > on their pool.
> >>
> >> As I understand it, GlassFish currently doesn't set anything on the
> >> pool either. We just haven't gotten around to implementing that because
> >> there hasn't been demand for it.
> >>
> >> > While I know that vendor specific properties themselves are always
> >> > non-portable, in the case of the standard and portable data-source
> >> > element it means the element can not be used at all with some vendors,
> >> > and that the vendor specific way to define data sources must be used.
> >> > I wonder if the EE spec can do anything to mitigate this somewhat.
> >>
> >> The only thing I can think of is requiring that *if* the vendor's
> >> connection pool has configurable properties, there must be a way to
> >> set them through properties in the DataSourceDefinition. But I think
> >> that might be going too far since it's getting into a very implementation
> >> specific area. Plus, it would be essentially untestable.
>