JBossDeveloper

You're likely to have around 1 class with this volume of annotations on ;-)

Francisco, to test compatibility between implementations, we use a TCK (Technology Compatibility Kit) (for all JCP specs). This verifies the implementation is compatible or not. However, due to the fact we are all human (well except you an Arbi who appear to be time travellers able to stretch time given how much you post ;-), not all aspects of all assertions of a spec end up getting checked.

However, unlike the JPA TCK, we are developing the 299 TCK, so you are in luck! Not only can you examine the tests, you can also contribute a test that shows what your interpretation of the spec assertion is, and checks the particular corner case you care about. And given your obvious passion, I am expecting at least 1 test a week from now on ;-)

I'm guessing we will be able to roll the additional tests into the maintenance release.

I personally don't see how that code would be improved (judged by reference to concrete factors like maintainability and understandability, rather than by purely subjective aesthetics) by splitting it across several XML-based deployment descriptors (or DSLs).

I also don't believe that it's typical.

Pete Muir wrote on Nov 07, 2009 19:30:


Francisco, to test compatibility between implementations, we use a TCK (Technology Compatibility Kit) (for all JCP specs). This verifies the implementation is compatible or not. However, due to the fact we are all human (well except you an Arbi who appear to be time travellers able to stretch time given how much you post ;-), not all aspects of all assertions of a spec end up getting checked.

I knew that, but AFAIK those TCK were only available if I paid a lot of money and/or signed an NDA.

However, unlike the JPA TCK, we are developing the 299 TCK, so you are in luck! Not only can you examine the tests, you can also contribute a test that shows what your interpretation of the spec assertion is, and checks the particular corner case you care about. And given your obvious passion, I am expecting at least 1 test a week from now on ;-)

Whoa... so the TCK is public? whoa... again... is that correct? wow... guess I'll have no option but to... start writing tests! (I would ask why the TCK for JPA is not open, but I think it is better to leave that to rest )

Gavin King wrote on Nov 07, 2009 21:48:


I personally don't see how that code would be improved (judged by reference to concrete factors like maintainability and understandability, rather than by purely subjective aesthetics) by splitting it across several XML-based deployment descriptors (or DSLs).

I also don't believe that it's typical.

May I suggest... that a way to improve it... would be to remove those annotations that cause conflicts because they mean the same de facto if not de jure. I have only played with Weld in an really really extremely superficial way, so I am not sure if that is happening in Weld annotations (as it does in JPA) but if it is, I hope a test case is written to disambiguate them (and if it is not, then since Pete has left me without any options... I guess I'll have to write it)

The CDI TCK is Red Hat's intellectual property and we decided to license it under ASL. The JPA TCK is the property of Sun (and Oracle?) and they determine the license.

That is good news, I do not know where I got the idea that TCKs had to be private... thanks for making the JSR 299 TCK open

I have to side with Francisco on this point against Gavin here(on half the story).  I have been wanting Hibernate NOT to do validation there for a while in a certain case.  On the inserts, it does NOT bother me as much BUT on the reading in of data, it kills me and has confused others(I have helped many people there).  In fact, I read one post on the hibernate forum where the person had assumed an update was being done and I had to explain hibernate validates on reads and that was his failure.

I really wish this check would go away myself as well, especially the check on reading in data.  the check on inserting/updating, I really don't care as much as it has not been confusing to developers as of yet.

LIE:s and other stuff can be fixed with portable extensions. I see Seam 3 more as a best of breed CDI plugins from the extensions ecosystem that have been tested and documented to work together

Seam 2 was a (much needed) hack on top of EE 6 that provided stuff to be included in EE 6. Seam 3 (and others) will be a testing ground for stuff to be included in EE 7. Just like a production database always has a top 10 SQL list of statements that can be tuned, Java development will always have a top 10 annoyances that can be tuned.

Injection is static (proxied)