users@javaee-spec.java.net

[javaee-spec users] Re: DataSourceDefinition

From: Antonio Goncalves <antonio.goncalves_at_gmail.com>
Date: Tue, 26 Aug 2014 22:58:33 +0200

Hum... I would not be too harsh. I quite use (and like) these annotations
for "quick development" purpose. This is important as we all want a Java EE
application to be developed quickly. It would be a step back to have to
always use an external JavaConfig specification just to deploy and use a
database. So I quite like it this way.

On the other hand, I never use this annotation on production. Do we have to
deprecate it ? Write on the Java Doc "do not use it in production" or maybe
make JavaConfig use this information. What about :

@Singleton
@Startup
@DataSourceDefinition(
        className = *"org.apache.derby.jdbc.EmbeddedDataSource"*,
        name = *"java:global/jdbc/chapter08DS"*,
        user = *"app"*,
        password = *"app"*,
        databaseName = *"chapter08DB"*,
        properties = {*"connectionAttributes=;create=true"*}
)
*public class *DatabasePopulator { ... }


This works fine in dev. And now, for production purpose, we use JavaConfig
to override this information :


<config>
  <dataSourceDefinition>
    <className>com.oracle.DataSource</className>
    <name>java:global/jdbc/myProductionDS</name>
    <user>tigger</user>
    <password>tigger</password>
  </dataSourceDefinition>
</config>
Best of both worlds : we keep on simplifying the platform with annotations
for quick development, and can add external configuration depending on
staging.

My 2 cents

Antonio


On Tue, Aug 26, 2014 at 8:22 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com>
wrote:

> Hi Arun,
>
> to enforce your "nobody uses it" the main issue is it is not usable
> for prod - often not the same team handles config and packaging - and
> portable since it doesn't integrate with common Java solution (common
> jdbc config - think to [dbcp] for surely the most known one). IMHO
> @*Definitions were an error and configuration should really be handled
> mainly outside the application and inside the application for embedded
> cases/cloud but using a CDI event if possible (didnt check but it
> should) or another standard listener where we can - as it is now more
> and more done - register resources.
>
> I think it is the main goal of config jsr.
>
> Would be great IMHO to get @*Definition deprecated if really not used
> (maybe same kind of polling that for @New can help) in favor of config
> jsr solution which should be really more powerful.
>
>
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-08-26 20:12 GMT+02:00 Arun Gupta <arun.gupta_at_gmail.com>:
> > There is clear evidence that nobody is using @DataSourceDefinition in
> > production code. See the conversation at:
> >
> > https://twitter.com/arungupta/status/504039335688404992
> >
> > Seems like its good only for demos. I'd urge platform EG and other EGs
> > in Java EE 8 to strongly consider adding a similar annotation.
> >
> > Cheers
> > Arun
> >
> > --
> > http://blog.arungupta.me
> > http://twitter.com/arungupta
>



-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>