Link Details

Link 1139541 thumbnail
User 1071861 avatar

By rmannibucau
via rmannibucau.wordpress.com
Published: Apr 14 2014 / 05:33

In a EE container you can either do everything manually or just use what the container provides. Of course the last one is the best since you decrease the code you need to maintain. That's great but sometimes you need to customize few things and for datasource for instance you can desire to customize the way you read the configuration. If you create it yourself how do you keep JTA support? TomEE has the answer!
  • 11
  • 0
  • 672
  • 2042

Comments

Add your comment
User 802739 avatar

Powerjohn replied ago:

3 votes Vote down Vote up Reply

Interesting, but why not use data-source element in web.xml?

User 1071861 avatar

rmannibucau replied ago:

-1 votes Vote down Vote up Reply

Because web.xml (or @DataSource) means you know when developing what is the datasource - which only works for embed datasources - (it is important to let prod teams configure prod resources and dev team use test datsources without changing the app/binaries). The other point is @DataSource (or web.xml equivalent) is quite broken in its config and is really linked to container so better to extract it from the app to keep app behavior stable. Finally it allows a soft migration for tomee users to fixed datsource to dynamic ones.

User 802739 avatar

Powerjohn replied ago:

1 votes Vote down Vote up Reply

We work with devops and always know the datasources we're developing for. We don't have dev teams and prod teams: just one multi-disciplinary team were we work together. We switch data sources for our target environment via our build tool (Maven / Jenkins). Meaning the configs for all our target environments are in the archive. We then commit it, and start a build. I don't think letting someone fumble with the config without checking the changes in is a good idea. It leads to "secret settings" that only some prod guy knows. When there's a bug nobody can reproduce it. Just have the config and code close and in plain sight.

User 1071861 avatar

rmannibucau replied ago:

-1 votes Vote down Vote up Reply

That's exactly the issue, you switch ds with the build tool where finally it should just have no link at all (if you have another customer you'll not add a profile with its own secret config for instance, even worse if you don't host it yourself). BTW in big companies the "only prod guys know the config" is just here by contract. Last point: don't forget the main point is to make it easy to users to get JTA integrated datasource when creating a custom datasource which is common to read config from enterprise repository or anything else.

User 802739 avatar

Powerjohn replied ago:

1 votes Vote down Vote up Reply

We don't have any external customers. We develop for our own company and we deploy to our own servers. A lot of people work that way. The market for selling Java EE products to external customers is smaller than running your own software (I think). In our company we had such bad experience with "only prud guys knowing config" (and only developers really knowing what should be configured) that we now have a contract that says if anyone tries to hide the config (effectively trying to make dev/prud split again) he can be fired. Also don't forget not only datasources need to be switched between servers. There are tons of other things which need to be done anyway, but then with different mechanism? (No JNDI is hardly a solution)

User 1071861 avatar

rmannibucau replied ago:

-1 votes Vote down Vote up Reply

Well depend companies, from my experience you have as much self hosting as not self hosting. That said it doesn't change the main issue: if you don't want something static or if you don't want the default container behavior you'll need to write a custom datasource and then you'll need to integrate it with JTA. What JavaEE added with @DataSource is broken by design and if it works for you it is finally you have simple needs and that's great but it is clearly not enough for all users. Another point is this kind of resource declaration is compatible with all tomee features...including the fact to use multiple drivers of the same datasource in the same app.

User 236075 avatar

henk replied ago:

1 votes Vote down Vote up Reply

>"if you don't want the default container behavior you'll need to write a custom datasource and then you'll need to integrate it with JTA" - With data-source/@DataSourceDefinition, you can provide an implementation for any custom kind of datasource. As long as its XA compatible, the container will take care of the JTA stuff. See http://jdevelopment.nl/switching-data-sources-datasourcedefinition for an example that both provides a custom datasource for data-source/@DataSourceDefinition as well shows how to (partially) switch datasources.

User 236075 avatar

henk replied ago:

1 votes Vote down Vote up Reply

">@DataSource is broken by design and if it works for you it is finally you have simple needs and that's great but it is clearly not enough for all users." - I've heard (you) saying that before, but I've never seen a clear statement of WHY it is broken. I think you once mentioned something about java:app and java:global being only available for EJB, but that's not the case. They are available for the entire AS including datasources. In Java EE 7 a bunch of additional resources can now be defined in the archive like JMS destinations. I think this is GREAT progress. As you mentioned yourself, there's "self hosting and non self hosting". Java EE should provide functionality for both use cases and not assume that non self hosting is the only way and that archives with unresolved dependencies are The Only True Way.

User 1071861 avatar

rmannibucau replied ago:

-1 votes Vote down Vote up Reply

Java:global was broken in EE 6, it is better in EE 7. About custom part EE spec still forget we define datasources from driver 80% of the time. So yes it is better and hopefully soon usable but custom things are still needed. ,

User 236075 avatar

henk replied ago:

1 votes Vote down Vote up Reply

What was fixed/changed for java:global in EE 7? The spec should indeed strongly mandate drivers can be loaded from the application archive. In GF 3 this didn't work, but seems to work in GF 4 and most other servers.

User 157014 avatar

rrahman replied ago:

3 votes Vote down Vote up Reply

I would also like to know what exactly we think is broken and why.

User 1071861 avatar

rmannibucau replied ago:

0 votes Vote down Vote up Reply

scope was clearly ambiguous: is global global or local to apps, what happen if two apps declare the same global name...? Can sound obvious but actually it is not at all regarding the way JNDI works. Then is JPA and @Resource(name) complaint with it? Spec was unclear you can use absolute paths. Some servers supposed yes, some other supposed not. etc...Then jndi resolution was not portable and today it is only cause servers more or less aligned on absolute name... TCKs were written to not check it correctly (I don't have access to EE 7 one yet so not sure it is totally fixed). Hacking this support in TomEE I recall I got some more surprises but don't have the details here right now but should have reported them somewhere (java.net IIRC).

User 157014 avatar

rrahman replied ago:

2 votes Vote down Vote up Reply

I don't get it. The spec make it crystal clear global is shared by all applications on an instance. It has always been the case that a duplicate JNDI binding in the same context is an error. The standard scopes are guaranteed to work with the lookup attribute, not the legacy name, etc attributes. The JPA spec will resolve any JNDI name, including the ones in standard scope. You can always continue to use non-standard "absolute" paths. If your real concern is around TCK coverage the correct way to handle it is reporting it to the appropriate EG or Oracle TCK liaison. Please be specific about what you would like changed. Exact spec references are best to suggest fixes.

User 157014 avatar

rrahman replied ago:

2 votes Vote down Vote up Reply

It is also important to remember that reference implementations serve as guidelines for all implementations. All of these issues have clear resolutions in GlassFish 4.

User 236075 avatar

henk replied ago:

0 votes Vote down Vote up Reply

>"is global global or local to apps, " - Global is global to all apps running on an AS. >"what happen if two apps declare the same global name" - It's a conflict and an error. >"Then is JPA and @Resource(name) complaint with it? " - yes, JPA and @Resource should have no need to be specifically compliant with java:global as it's the one namespace that can be resolved from anywhere. >"TCKs were written to not check it correctly" - I can imagine that to be true (JASPIC, cough, and JPA cough), but without access to the TCK it's hard to say for sure. The only thing we can be sure about is if a broken implementation gets certified anyway, then the TCK is certainly lacking. We know from evidence that a few extremely bad and barely or even non-working JASPIC implementations got certified so the JASPIC TCK can't test much, and we also know from evidence that Hibernate has had plenty of things that just didn't work while the servers that used that version were certified, so the JPA TCK must have (had) many omissions too.

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

From my personal experience, the TCK is quite good. All software has bugs, the TCK is no exception. The most logical way to get it fixed is by properly reporting issues.

User 236075 avatar

henk replied ago:

0 votes Vote down Vote up Reply

>"Hacking this support in TomEE I recall I got some more surprises " - I remember you hacking on the java:global and java:app support for @DataSourceDefinition in TomEE. Really good job of you that you eventually got it working :)

User 1071861 avatar

rmannibucau replied ago:

-1 votes Vote down Vote up Reply

Hi, ok let me try to be a bit more precise (and maybe we should stop it cause we all agree EE is going in the right way, this feature was not against EE at all just an answer to a user need): In EE 6 spec it is clear that EJB and java:global is working and that datasources can use java:global. So all is fine...excepted that java:global is not defined. It is as global as the container wants (single node, cluster, world, other...). It is written that global naming can conflict or not too. So basically global is not defined. Regarding your phrasing "instance" was not defined. About TCKs: you are both right: not enough tests but already a lot limiting side effects (between impl) for serious impl - you can always mock an impl but then you are quickly ridiculous. About "glassfish as reference" let me disagree since GF is pushed by deadline and sometimes it just impl it wrongly (CDI was a good exemple where GF used other servers to relax constraints - see BDA). In particular in TomEE project we try to make EE easy first, that's the advantage to not be a $$ company ;). To conclude about JNDI I'd say what is missing is more or less contexts or CDI: in CDI @AppScoped is ambiguous when not in an ear but you can do your own contexts making it clear...why not the same for jndi? java:context/my-scope/....Would need a container integration (can't be done at app level if scope > app one) but would make it clear. You could get java:context/cluster, java:context/node....

User 157014 avatar

rrahman replied ago:

0 votes Vote down Vote up Reply

Quite frankly you seem to be missing quite a bit of historical context on Java EE. Java EE has always avoided defining clustering for very good reasons and leaves those features vendor specific. That's unlikely to ever change. An instance is also very clearly defined to be a single JVM instance. Your remarks about GlassFish is blatantly incorrect. The goal of GlassFish is always to provide a high quality reference implementation. We have historically been the fastest to address spec related bugs and doing scheduled bug fix releases. GlassFish is also entirely non-commercial, so I don't get your comment about money. You need to be a bit more clear about what you are saying about CDI and JNDI. As such, it's making little sense. Or are you still under the impression that Java EE defines clustering? I do agree that it seems that you need to stop or make a bit more sense.

User 1071861 avatar

rmannibucau replied ago:

-1 votes Vote down Vote up Reply

I agree on the "for good reason" but actually the spec is clearly ambiguous on this point. I don't say spec defines cluster but spec doesn't say if it includes cluster or not, it opens ambiguity in its phrasing: 5.2.2 of EE 6: " java:global - Names in this namespace are shared by all applications de- ployed in an application server instance. Note that an application server in- stance may represent a single server, a cluster of servers, an administrative domain containing many servers, or even more. The scope of an application server instance is product-dependent, but it must be possible to deploy multiple applications to a single application server instance. " GF is clearly pushed by Oracle whatever you say so it is kind of $$ since it is the first image of EE even if it is a great community. Due to it it also takes longer to fix bloker issues since it is harder for GF to not respect the spec (well here I meainly speak about BDA where users needed to explode their webapp in web-inf/classes to get something working for while). About CDI/JNDI: CDI defines how to create a custom context/scope. Would be nice to get it in JNDI too and not relying on what you bind in JNDI for that. That said EE will surely go to CDI even for resources resoution (even for datasource in persistence units) so JNDI can also be let it this way and slowly be less and less used (that's more or less what it looks like regarding users needs/usages).

User 157014 avatar

rrahman replied ago:

0 votes Vote down Vote up Reply

Let me repeat it for you again - Java EE never defines clustering behavior. It specifies only single JVM instance behavior and that's what the TCK covers. The text you are referencing simply means that the spec does not disallow clustering. If you are trying to say GF is careful not to violate the spec that is 100% accurate. That's what the reference implementations of all specs do and what all good implementations should be doing. If TomEE is intending to violate the spec is some fashion, we need to know about it and deal with it ASAP. We have no foreseeable plans to replace JNDI with CDI so I really have no idea what you are talking about. We asked the community in our recent survey whether we should try to replace @Resource and there was little support to do that (as we suspected all along). Lastly, let me repeat for you loud and clear again - GlassFish is 100% open source, 100% free and 100% non-commercial as the RI for Java EE. Trying to suggest anything else is pure nonsense.

User 157014 avatar

rrahman replied ago:

0 votes Vote down Vote up Reply

Other than the completely non-standard clustering you keep going on about, what's the compelling use case for more JNDI scopes exactly? Why does a user care? Do you understand that users can use whatever JNDI scheme they choose already besides the ones the standard recommends?

User 1071861 avatar

rmannibucau replied ago:

-1 votes Vote down Vote up Reply

You don't get me at all I think. I don't care about clustering (re-read the thread and *you* speak about it actually, not me), but the spec just says it doesn't care about global scope definition so the bahavior you can get is just undefined. If it is clear for you it is single node please ask to update the spec to say it and make it clear 2 apps defining same global resource will fail. See the paragraph I pointed out, it is clear we don't know what it will do. I didn't say glassfish is commercial neither, I said Oracle used it in such a way which is really different. About CDI/JNDI: deltaspike prooved it is a need and that some users would be happy to get rid of JNDI in their interface (I guess behind the hood containers will still use it since it is really important internally). About JNDI schema: IIRC you can't bind wherever you want ATM, not portably at least....Finally the point was not really about location (sorry if it was not clear) but about a throught to make obvious the scope of a bound resource. In other word avoid the ambiguity of global scope and open the door to whatever scope the user can need as did CDI. PS: I'm on IRC (freenode #openejb for instance) if you want to speak about, can make it easier maybe

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

Let me repeat for you once again - global scope as it is defined for a single JVM is crystal clear. It is shared across all applications in the JVM instance period. That means any conflict is by definition an error. There is absolutely no clarification necessary period. Don't believe it? Go ask the spec lead for clarification (I'm going to guess you didn't bother doing that). They will be happy to set you straight quickly. I've already told you the community has told us loud and clear through the survey they don't care about CDIfying JNDI. You can absolutely use any scheme for the JNDI name you want via @DataSourceDefinition and use it portably in a single JVM instance. You are right, I don't get the repetitive nonsense at all. From what I see, I think there's little value in talking since you are obviously not interested in listening clearly. I am really beginning to wonder what is going on with TomEE now...

User 1071861 avatar

rmannibucau replied ago:

-1 votes Vote down Vote up Reply

This sentence (taken from the spec) is clearly not aligned on what you say: "java:global - Names in this namespace are shared by all applications deployed in an application server instance. Note that an application server in- stance may represent a single server, a cluster of servers, an administrative domain containing many servers, or even more. The scope of an application server instance is product-dependent, but it must be possible to deploy multiple applications to a single application server instance. "

User 157014 avatar

rrahman replied ago:

2 votes Vote down Vote up Reply

Honestly, I'm beginning to think you have a problem with English comprehension. What I am telling you is exactly what the spec says. Yet again, that sentence is telling you global is shared across applications in an instance. For the purposes of the spec, that means for a single JVM instance since Java EE does not standardize clustering. The spec is also telling you that you may do what you want in a product specific way for clustering. Still don't get it? Ask the spec lead instead of repeating nonsense, confusing others and yourself. Another suggestion - ask your project lead David Blevins. He has been around long enough to know better and is a native English speaker.

User 1071861 avatar

rmannibucau replied ago:

-1 votes Vote down Vote up Reply

That's the point. The spec doesn't standardize it...so it is useless. Not closing the door to product specific vendors is important but not making choices in the spec itself just means you don't know what you get. The last sentence in particular suppose you'll not get a conflict if two apps use the same name. I get what you say and it totally makes sense but that's not what you get reading the spec for sure, having or not issue in english. It is just not explicit enough. This is not the only point where ambiguity is, ejb-jar.xml place is too for instance (the spec wants a single one for war but reading the spec (didnt check EE 7 wording) you can put it in META-INF for each jar...which is false for wars). Once again not sure how we ended up on such a discussion which has absolutely no link with the original article.

User 157014 avatar

rrahman replied ago:

0 votes Vote down Vote up Reply

Yet again - clustering has never been standardized and never will. The world isn't perfect and insisting upon perfection is foolish. There's clearly value to standardize singe JVM behavior rather than not standardizing anything at all. That a far cry from "useless". You should absolutely get an error in case of a single JVM. Yet again, don't want to listen to me ask David or the spec lead and they will set you straight right away as to what the spec means. The EJB jar bit is nonsense too and again it seems you have language comprehension issues. That was done as part of the work for EJB Lite/EJB 3.1. In fact that enhancement came from OpenEJB so David will know it well.

User 1071861 avatar

rmannibucau replied ago:

-1 votes Vote down Vote up Reply

Exactly...David said me the opposite about ejb-jar.xml (a clear "we don't want")...I'll ping him again when he'll be available but I'm pretty sure something was missed and not only on my side.

User 157014 avatar

rrahman replied ago:

2 votes Vote down Vote up Reply

Good - copy me on the email and I'll help set you straight. David was active on the EJB 3.1 EG. Mention the global nonsense there too so that can also be straightened out for you.

Add your comment


Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.

Voters For This Link (11)



Voters Against This Link (0)



    Java Performance Optimization
    Written by: Pierre-Hugues Charbonneau
    Featured Refcardz: Top Refcardz:
    1. Design Patterns
    2. OO JS
    3. Cont. Delivery
    4. Java EE7
    5. HTML5 Mobile
    1. Node.js
    2. Debugging JavaScript
    3. OO JS
    4. JSON
    5. Ajax