And if you are talking about a better Spring, Seam does not even have the equivalent of Spring's JdbcTemplate which is a very useful data access component which makes JDBC much cleaner and easier (i.e. no connection leaks and boilerplate code). In some cases JPA and/or Hibernate is not a good option for legacy schemas which may be missing foreign keys and not in 3NF, for example. So JDBC or iBATIS (sql mapping) may be better options. Of course, we can use Spring modules as integrations in our Seam apps.

People are going to evaluate EE 6 and ask what does this stack offer that we can't currently accomplish with Spring 3 and dm server?

Seam does not even have the equivalent of Spring's JdbcTemplate which is a very useful data access component which makes JDBC much cleaner and easier.

I'm sure you'll find it's trivial to integrate a JDBC framework as a portable extension to CDI. The idea that anyone would choose to adopt the entire Spring application architecture just to get a JDBC framework is absurd.

I'm sure if someone cares enough, they will port the Spring JdbcTemplate stuff to CDI. That's not at all a difficult task.

(It's even completely trivial to integrate iBATIS in Seam.)

People are going to evaluate EE 6 and ask what does this stack offer that we can't currently accomplish with Spring 3 and dm server?

I certainly hope they do, since there are so many good answers to that question.

Arbi Sookazian wrote on Nov 04, 2009 06:41:
People are going to evaluate EE 6 and ask what does this stack offer that we can't currently accomplish with Spring 3 and dm server?

Shouldn't the first question asked be Now that we get this for free as a standard, what added value do we get from a VC backed framwork? ;-)

And yes, Spring Framework is open source but any project has a number N where N is the number of people removed from the top of the hierarchy after which the project is pretty much doomed. Seam is not exception. That's why standards are good. A vendor switch results in rewriting but the amount of work shouldn't be huge if both are based on the same standard.

what added value do we get from a VC backed framwork?

Rrrrm, that would be a VMWare backed framework now, Nick :-)

Gavin King wrote on Nov 04, 2009 08:36:
what added value do we get from a VC backed framwork? Rrrrm, that would be a VMWare backed framework now, Nick :-)

Oh right! Forgot about the deal. But the point stands, if company X pays big bucks for something, they will want to have their ROI even if it means twisting the product to whatever their needs happen to be.

Sounds a but FUD:dy but it's not paranoia if they really are out to get you ;-)

Perhaps a lot of these technologies, concepts and integrations, etc. are trivial for the JBoss team. Not for me and other corporate developers in the real world. I spent hundreds of hours over the last few years learning EE 5 and Seam, etc. and still don't consider myself a master by any means.

Remember, just b/c it's trivial for you (someone who designed and implemented an ORM technology, for example) does not mean it will be trivial for everyone else.

Is it trivial to use Hibernate with legacy db schemas that don't have proper referential integrity (i.e. foreign keys) defined in all the places they should be defined? Most likely not, and then you may choose to use iBATIS or Spring JDBC (yes, I know Hibernate supports stored procs but JPA 1.0 does not AFAIK).

One of these days, web app technology with AJAX and distributed tx's and HTTP/REST will be very old school. Isn't the Commodore 64 completely forgotten now?

That is a little bit like the impression SpringSource's (that would be VMWare now, too ;-) lack of interest in the DI standard (JSR-330) they actually had SpecLead responsibilities in seemed to me...

Twisting the product of course means, people not only have to buy or at least download the latest version, you can also justify the low innovations elsewhere with some changes in this area. And have people pay for training to adopt to those twists.

Arbi Sookazian wrote on Nov 05, 2009 00:51:
Perhaps a lot of these technologies, concepts and integrations, etc. are trivial for the JBoss team. Not for me and other corporate developers in the real world. I spent hundreds of hours over the last few years learning EE 5 and Seam, etc. and still don't consider myself a master by any means. Remember, just b/c it's trivial for you (someone who designed and implemented an ORM technology, for example) does not mean it will be trivial for everyone else.

Totally agree with you here.

Is it trivial to use Hibernate with legacy db schemas that don't have proper referential integrity (i.e. foreign keys) defined in all the places they should be defined? Most likely not, and then you may choose to use iBATIS or Spring JDBC (yes, I know Hibernate supports stored procs but JPA 1.0 does not AFAIK).

It is not trivial, of course (it is not even trivial to deal with nulls between different JPA implementations)

One of these days, web app technology with AJAX and distributed tx's and HTTP/REST will be very old school. Isn't the Commodore 64 completely forgotten now?

I can not wait for the day when the world finally leaves AJAX, HTTP and REST behind!

Perhaps a lot of these technologies, concepts and integrations, etc. are trivial for the JBoss team. Not for me and other corporate developers in the real world.

I didn't say that you had to personally do it. But someone will do it. That's the value of having a standard like CDI and the portable extension SPI: it's a common environment that open source framework developers can target. I certainly hope that JBoss are not going to be the only folks building portable extensions for CDI. The whole idea is to open up a new ecosystem there.

Enjoy

Kungfu Panda, please use your real name here. We're fussy about that stuff ;-)

perhaps that is his real name (e.g. Marilyn Manson and Hollywood actors). and does it really matter? It's bad enough that we're forced to use action-based MVC frameworks in the real world like Struts 1.x and Spring MVC. I'm really starting to get a feel for how unnecessarily complex and over-complicated Spring 2.x framework really is... Missing Seam... Juergen Hoeller is a dork.

One goal of the JPA specification was to make the technology pluggable. To enable this, the roles of container provider (the container or the side that has control of the runtime threads and transactions), and persistence provider (the provider or the part that implements the persistence API and manages the persistent entities) were defined, and a service provider interface (SPI) binds the two at deployment and runtime. A compliant JPA host container correctly implements this SPI from the container perspective. A compliant JPA persistence provider implements the SPI from the provider perspective. If both sides follow the rules, a compliant container should be able to run any compliant persistence provider implementation, and similarly, a provider should plug into any container.

http://java.sys-con.com/node/366275

The SPI idea is a good one...

btw, I said: Not for me and other corporate developers in the real world.

But that's ok. JBoss is human, or perhaps becoming oragnicized with OSGi compliance?

Arbi Sookazian wrote on Nov 06, 2009 00:35:
One goal of the JPA specification was to make the technology pluggable. To enable this, the roles of container provider (the container or the side that has control of the runtime threads and transactions), and persistence provider (the provider or the part that implements the persistence API and manages the persistent entities) were defined, and a service provider interface (SPI) binds the two at deployment and runtime. A compliant JPA host container correctly implements this SPI from the container perspective. A compliant JPA persistence provider implements the SPI from the provider perspective. If both sides follow the rules, a compliant container should be able to run any compliant persistence provider implementation, and similarly, a provider should plug into any container.

Nice idea in theory (that about multiple compatible JPA implementations) not true in practice, but nice in theory.

The SPI idea is a good one... btw, I said: Not for me and other corporate developers in the real world.

As I was saying, nice in theory, sadly we work in the real world. Unless the TCK (or something equivalent that makes it possible for the community to objectively test compatibility) because easy available interchangable SPIs will remain as only a nice dream.

But that's ok. JBoss is human, or perhaps becoming oragnicized with OSGi compliance?

Not sure what do you mean, but I certainly hope JBossAS (and all other Jboss projects) gain OSGi support soon.

Nice idea in theory (that about multiple compatible JPA implementations)

Francisco, I'm getting increasingly annoyed with you posting the same pet issue on every single thread in every message board. The Hibernate team has many important issues to deal with like implementing JPA2 and fixing actually important bugs. The question of what exception type gets thrown when you have marked your attribute as not-null at the schema level, but not at the object level (which is more or less your own programming error) is just not one of them. So please give it a rest for f***s sake.

Unless the TCK (or something equivalent that makes it possible for the community to objectively test compatibility) because easy available interchangable SPIs will remain as only a nice dream.

The 299 SPI is part of the spec and therefore it is of course tested by the TCK.

Is it going to be as well-tested by the TCK as other parts of 299, well, no, probably not. Is it likely that there will initially be some teething problems with some kinds of portable extensions? Yes, I imagine there probably will be. However, I'm quite certain that the Open Web Beans, CanDI and Weld teams will all be very keen to work together to get the wrinkles ironed. If anything needs spec clarification, we can do that in the first maintenance release of 299.

However, developers whose brains have been turned to mush by overexposure to the Spring framework think that they have hundreds of beans which might vary depending upon the deployment. That's how they justify writing great gobs of XML to explicitly list out all the classes in their application.

http://in.relation.to/Bloggers/MakingExternalResourcesConfigurableWithoutLotsOfXML

that was pretty funny. to be fair, it's also heartily laughable the abysmally low corporate adoption of Seam thus far (over 3 years since initial GA release).

class TestCustomerDatabase {
   static 
   @Resource(lookup="java:global/env/jdbc/TestDatasource") 
   @Produces @Alternative @CustomerDatabase 
   Datasource testCustomerDatabase;
}

What about annotation hell? Isn't this a good example? Is it acceptable to apply say 5-10 annotations on a single method??

I'm telling you, ORM needs to be replaced by another better solution, like OODBMS as suggested by Ted Neward, etc. and metadata needs another solution, moving away (somehow) from XML or annotations. Even dependency injection will be replaced by a better solution. Let's leave the hard work up to Francisco ;)

OODMS? And you're talking about low market penetration for Seam in three years? Object databases have been around for 20+ years by now ;-)

And as I recall saying, annotations might not be the best thing but it's what the de-facto standard currently. If you have many things to describe about something, you are going to need a few more words than usual. Or annotations. Or foobars (or whatever the new tech will be). Actually, it's quite a nice example you got there:

@Produces @Alternative @CustomerDatabase

it reads almost lite english. If you need to describe that about a point in the code, how could you do it any simpler?

Gavin King wrote on Nov 06, 2009 02:54:
Nice idea in theory (that about multiple compatible JPA implementations) Francisco, I'm getting increasingly annoyed with you posting the same pet issue on every single thread in every message board. The Hibernate team has many important issues to deal with like implementing JPA2 and fixing actually important bugs. The question of what exception type gets thrown when you have marked your attribute as not-null at the schema level, but not at the object level (which is more or less your own programming error) is just not one of them. So please give it a rest for f***s sake.

IMO is completly on topic, we are talking about the creation of an SPI ecosystem around JSR 299, and you can not really have compatibility without an open and public way of testing for that compatibility. I am also getting a little tired of you saying that bug is my programming error that bug is because Hibernate calls org.hibernate.engine.Nullability.checkNullability to verify something that according to your interpretetion of the the JPA spec should NOT be verified, you wrote it yourself:

Gavin King wrote: Hibernate' behavior is correct. nullable=true is defined by the spec as a hint for schema generation.
http://java.sun.com/javaee/5/docs/api/javax/persistence/Column.html#nullable()
For object-level validation, use optional=false:
http://java.sun.com/javaee/5/docs/api/javax/persistence/Basic.html#optional()

But hibernate uses nullable for object-level validation not only as a hint for schema generation. And the spec says nothing about what to do if nullable and optional contradict each other, so each implementation deals with that situation different.

I feel concerned that you are going to follow the same approach when other implementations of the JSR 299 follow the spec as you think it is implemented in Weld, and not as it is actually implemented. I think it is a valid concern to raise here: There should be an easy open way to test if all the implementors of a Spec are actually compatible, I would raise that issue at the JSR forum, but anyone can see that nobody answers post sent there.

Just answer this simple question: What part of the spec says that org.hibernate.engine.Nullability.checkNullability should exist and do what it does (use nullabe=true as object-level validation)?

The answer is simple:None. org.hibernate.engine.Nullability.checkNullability might have been a good idea, but right now, is only there to make Hibernate incompatible with the JPA spec.

I can understand that you feel annoyed by me, but imagine how I feel after the you simply rejected my very valid bug report and after that decided to ignore all my posts (posts I made to the Hibernate forum, not here) for the last 6 months?

Do you really think that helps me (or anyone) believe that standardization issues between JSR 299 implementations are going to be easy to fix?

Very clearly, you have a programming error. You have an attribute declared @Basic(optional=true) @Column(nullable=false). How is that possibly meaningful?! You have told Hibernate that you have an attribute which can be null, but which is going to be persisted to a column declared NOT NULL. How is that possibly going to work? You have an error. Please stop blaming Hibernate for behaving a little bit strangely when given a mapping that is completely wrong and nonsensical. Actually, in this case it would be better if Hibernate refused to start, since it has been given a broken mapping.

Francisco this is not a Hibernate forum and if you keep on about this stuff I will start deleting your posts. You are clearly way off topic. No, this has nothing at all to do with SPIs and portable extensions.

Now please can we talk about something that people other than you care about?

Now please can we talk about something that people other than you care about?

1. CBauer typically deletes or deactivates the user's account for this forum in these types of scenarios. You're being nice (so far)...

Francisco, even if you're wrong or right, go rant on the appropriate forum. You're out of line...

GKing is not forcing anyone to use his frameworks. Open a JIRA if required. Unfortunately, sometimes we're stuck with the corporate standards...

whoops! sorry bout that. I meant to type: +1...

I just can not belive that even when I put it as a simple question you managed to ignore and misunderstand the issue... this is so sad.

Arbi, threats are a great way to win a discussion (who cares if you are right or you are wrong), keep doing it, hope you never have to be in my place.

it's the way GKing is and will be and what makes him unique. you have to play by their rules. it's their forum and they're in charge...

let's set aside personal issues and attitudes, etc. and continue plz... we're all winners here ;)

so, @Produces @Alternative @CustomerDatabase can be morphed or concatenated into @ProducesAlternativeCustomerDatabase perhaps? Why not just one annotation to make things simpler? Unless we're concerned about fine-grained meta-data reusability...

I don't want to see like 12 @ signs before my methods, you know?

Here is an example, (sorry it's Hibernate, but not trying to bash Hibernate at all, ok?):

@ManyToOne( fetch = FetchType.EAGER, cascade =   
   { javax.persistence.CascadeType.PERSIST, javax.persistence.CascadeType.MERGE } )  
 @JoinColumn( name = "PERSON_DETAIL", nullable = false )  
 @Where( clause = "ACTV_ID = 'T'" )  
 @Cascade( { CascadeType.SAVE_UPDATE, CascadeType.MERGE, CascadeType.DELETE } )  
 @Cache( usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE )  
 @EqualsMember  
 @NotNull  
 @Valid  
 @Message( "${msg.invalid.person.detail}" )  
 @XmlElement( name = "person-detail", required = true )  
 public PersonDetail getPersonDetail()  
 {  
     return personDetail;  
 } 

http://www.coderoshi.com/2008/09/annotation-hell.html

So how can Weld improve this scenario? Do stereotypes come into play here for refactoring this? I'd still prefer this to XML hell but this is difficult to read, no?

CDI provides the ability to define an annotation that represents a deployment scenario. These annotations are called alternative stereotypes.

http://www.jboss.org/feeds/post/making_external_resources_configurable_without_lots_of_xml

Arbi Sookazian wrote on Nov 06, 2009 20:36:
it's the way GKing is and will be and what makes him unique. you have to play by their rules. it's their forum and they're in charge...

Yes, you are right, it is not worth the effort, I do not know what got in to me.

let's set aside personal issues and attitudes, etc. and continue plz... we're all winners here ;) so, @Produces @Alternative @CustomerDatabase can be morphed or concatenated into @ProducesAlternativeCustomerDatabase perhaps? Why not just one annotation to make things simpler? Unless we're concerned about fine-grained meta-data reusability...

You really think @ProducesAlternativeCustomerDatabase is a better idea? less @ is, IMO not such a great advantage and you would lose flexiblity to mix you annotations in new ways...

I don't want to see like 12 @ signs before my methods, you know?

Why? What is you problem with @? (You can always switch to .NET and use [ ] for you annotations... ;-)

Arbi Sookazian wrote on Nov 06, 2009 20:45:
Here is an example, (sorry it's Hibernate, but not trying to bash Hibernate at all, ok?):

@ManyToOne( fetch = FetchType.EAGER, cascade =   
   { javax.persistence.CascadeType.PERSIST, javax.persistence.CascadeType.MERGE } )  
 @JoinColumn( name = "PERSON_DETAIL", nullable = false )  
 @Where( clause = "ACTV_ID = 'T'" )  
 @Cascade( { CascadeType.SAVE_UPDATE, CascadeType.MERGE, CascadeType.DELETE } )  
 @Cache( usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE )  
 @EqualsMember  
 @NotNull  
 @Valid  
 @Message( "${msg.invalid.person.detail}" )  
 @XmlElement( name = "person-detail", required = true )  
 public PersonDetail getPersonDetail()  
 {  
     return personDetail;  
 } 

Arbi... An question about annotation hell with @NotNull, @JoinColumn(nullable = false)? Please don't torture me with such flamebait!

My tooling will of course color them nicely by category and allow me to fold/hide away those annotation categories I'm not interested in...

Arbi Sookazian wrote on Nov 06, 2009 00:35:
perhaps that is his real name (e.g. Marilyn Manson and Hollywood actors). and does it really matter?

Yes, we feel it does. There is quite a body of research about how people will behave very differently when on in an anonymous forum (and in general behave in a way that is considered worse by most societies) - consider for example Anonymous Coward on TSS. One way to combat this is to require people to use a real name as it decreases the level of anonymity.

Right, the issue here is that we have a conflict between:

• Make the TCK perfect (which takes time)
• Actually finish JSR-299

(FYI for the people who luckily know less about JCP process than Gavin and I do, you can only fix existing tests in a TCK after the spec is final, you can't add tests).

So, to get around this, we plan two branches of JSR-299 TCK development after the spec is final:

• 1.0.x - bug fix only releases on the submitted TCKs. Implementors must pass the all these tests (likely about 800 covering 80% of the spec assertions) to be deemed compatile
• 1.1.x - bug fixes plus new tests. Implementors are strongly encouraged to pass this version of the TCK (we certainly will for Weld, and knowing the CanDI and OWB guys, I'm pretty sure they will be keen to do this too - after all, who wouldn't, as it ensures you have better implementation!). The aim for this TCK will be 99.9% coverage of assertions :-)

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.

I am now curious about this. Hibernate validates on read? Like when executing HQL or what? I never experienced this using Hibernate 3 as a persistence provider for JPA 1.0. Is this something that can be configured in the persistence.xml?

no, no, no; off topic, out of line...

and here's what CBauer would say: submit a patch!

can Weld be used with front-controller (action) based MVC frameworks like Struts 1.x or Struts 2?

And I just learned that Struts 2 uses Guice??? type-safe DI...

Along the way, you get a quick tour of some of the frameworks within the framework that is Struts 2 -- namely OpenSymphony WebWork/XWork, Guice and Dojo -- and find out how Struts 2 integrates these powerful allies to make Ajax development a pleasure.

http://www.javaworld.com/javaworld/jw-08-2007/jw-08-ajaxtables.html

wouldn't it be nice if one day, one release of EE X, we could create Java applications using the actual entire EE stack (e.g. JSF, JPA, EJB, Weld, etc.) and not even have to think about deviating away from the official JCP-endorsed stack and create these Frankenstein stacks?

Like .NET, right? Use what's out of the box...

1) use reference impls as base unless otherwise required 2) use the libraries/JARs you need (or profiles, as in if you don't need web services, pick the lite profile) 3) select an app server (servlet container and/or EJB container) 4) select an IDE 5) select a language(s) as JVM languages are becoming popular you know 6) design db, UML, classes, etc. and code!

No more researching this AJAX framework, this DI solution, etc. unless you really need to...

wouldn't that be nice?

So in a way I'm advocating little (or no) use of Seam 3 when creating a EE 6-based application. Why Seam now?

added value: PDF, excel, remoting, conversational web services, SMPC, hmmmm... and the list goes on.

Well, IMHO, as much as I like Seam 2.x, I still think Seam was/is a big hack in EE 5. Although it was necessary to prototype ideas that made it into JSF 2.0 and CDI (among other specs?)

But will we really need Seam in EE 6 apps? Won't there be another way to avoid LIEs without Seam? And the manual flush should have made it into JPA 2.0, no?

Well hopefully the performance issues with JSF/Seam will be alleviated fully with Seam 3...

For example, how does the injection work in Weld? Is it similar to Seam as being dynamic injection? What if you don't want some instance variables to be injected for some methods as an optimization? It's unnecessary overhead when they're all being refreshed all the time for all business (interface) method calls...

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)

and here's what CBauer would say: submit a patch!

Must…resist…urge…to...answer...aaaarghhhh: All that needs to be done to fix this is to delete the org.hibernate.engine.Nullability.checkNullability method... do I really need to submit a patch with that?

Sorry, I was not strong enough to resist :'(

Arbi Sookazian wrote on Nov 10, 2009 01:27:
Like .NET, right? Use what's out of the box...

The problem is that .NET box has a lot of things JEE does not have (Process isolation, Better Generics Support, LINQ, closures, continuations, better DateTime API).. (and JEE also has a lot of things .NET does not have (the UI is truly multi platform, different vendors to choose, multi platform distributed transactions, older and more stable ORMs, lots of free and open source code, vibrant open-source communities )). If I have learned something in all my years of coding... is that all platforms are imperfect....

What I would love to see is strong vendor supporting IKVM to the point that it becomes much easier to share code between Java and .NET (Perhaps now that the JVM is open it could happen)

Nicklas Karlsson wrote on Nov 10, 2009 08:06:
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.

You mean:

Seam 2 --> EE 5 (JSF 1.x and EJB 3.0)

Seam 3 --> EE 6 (JSF 2.0 and EJB 3.1)

right?

EE 6 RI is not even out yet in final release, correct?

Arbi Sookazian wrote on Nov 10, 2009 01:39:
So in a way I'm advocating little (or no) use of Seam 3 when creating a EE 6-based application. Why Seam now? added value: PDF, excel, remoting, conversational web services, SMPC, hmmmm... and the list goes on.

Exactly, Seam becomes JBoss extensions for (or on top of) JSR-299

Well, IMHO, as much as I like Seam 2.x, I still think Seam was/is a big hack in EE 5. Although it was necessary to prototype ideas that made it into JSF 2.0 and CDI (among other specs?)

I agree.

But will we really need Seam in EE 6 apps? Won't there be another way to avoid LIEs without Seam?

Only if the JPA 2.0 guys decided to alter the spec to avoid LIEs.

And the manual flush should have made it into JPA 2.0, no?

They do not see any reason to do that, and frankly, I do not blame them (I do not see any reason either). BTW Arbi, you are asking too much things about JPA writing in this posts... you could get banned, this forums are not for discussing JPA ;-).

Well hopefully the performance issues with JSF/Seam will be alleviated fully with Seam 3...

Hopefully, but I think many of the performance issues are due to the architecture of JSF... hopefully JSF 2.0 will help with that... but then again, this is not a forum to discuss JSF ;-)...

Don't you think there should be a place where discussing any implementation of JSF, Weld, JEE, JPA should be on topic always? After all, all this efforts are to integrate this 3 technologies, and if there is a bug in one of them that causes problem precisely when it is interacting with the others there is just no (AFAIK) single place where is is right to ask about it.

Francisco Peredo wrote on Nov 10, 2009 17:03:
Don't you think there should be a place where discussing any implementation of JSF, Weld, JEE, JPA should be on topic always? After all, all this efforts are to integrate this 3 technologies, and if there is a bug in one of them that causes problem precisely when it is interacting with the others there is just no (AFAIK) single place where is is right to ask about it.

I'm sure GKing will completely disagree with you on that. Your inquiry belongs on the (languishing?) Hibernate forum or Hibernate mailing list. I've noticed that posting there does not usually get a reply (sad).

We need to focus on CDI/299, the spec, the RI (Weld), the TCK, design patterns and nothing else. And be sure to read the spec 10 times in a row prior to asking any questions here otherwise GKing and others may prompt you to go read the spec which I don't blame them for saying (partially). Although specs are typically dry and boring, no offense...

If you have any doubts about EE 6 and/or CDI/Weld adoption (in the future of course), then you must direct them to the vendors and customers. This is not apparently not the appropriate place to discuss this.

Concepts and code you can discuss.

So why static injection rather than dynamic injection in Weld/CDI? I thought in Seam, dynamic injection was the big advantage over Spring's static setter or constructor injection...

BTW, is there anybody writing a CDI/Weld book or will that sort of be covered in an updated Seam 3 book (the core section)?

Arbi Sookazian wrote on Nov 10, 2009 17:35:
Although specs are typically dry and boring, no offense...

I can live with dry and boring specs (it is painful, but I can endure it), the thing I can not endure is ambiguous specs, so I am really happy that the TCK of JSR-299 is public, that way there is not room for ambiguity, if it is in a test, it has to pass the test, if it is not in a test, then a test has to be written. I hope one day all TCKs become open and freely available...

Ummm, yes (probably, depending on what the arrows mean). Not that I'm sure where the question was going, but...

Arbi Sookazian wrote on Nov 10, 2009 17:35:
So why static injection rather than dynamic injection in Weld/CDI? I thought in Seam, dynamic injection was the big advantage over Spring's static setter or constructor injection...

Performance and simplicity of design, perhaps? I'm not that familiar with Spring DI

Arbi Sookazian wrote on Nov 10, 2009 17:35:
BTW, is there anybody writing a CDI/Weld book or will that sort of be covered in an updated Seam 3 book (the core section)?

I'm sure there will be. There are not m(any?) core technologies in the EE that hasn't been covered by multiple books.

So why static injection rather than dynamic injection in Weld/CDI? I thought in Seam, dynamic injection was the big advantage over Spring's static setter or constructor injection...

In CDI we use proxies to achieve approximately the same effect. It's stll dynamic, just a different kind of dynamic.

Gavin King wrote on Nov 10, 2009 20:07:
So why static injection rather than dynamic injection in Weld/CDI? I thought in Seam, dynamic injection was the big advantage over Spring's static setter or constructor injection... In CDI we use proxies to achieve approximately the same effect. It's stll dynamic, just a different kind of dynamic.

Plz don't obfuscate the answer :). Elaborate on different kind of dynamic. What does that mean? And remember, I don't like how Seam refreshes all the instance variables in a Seam component for every public/interface method call. Seems like a waste and performance hit if it's not customizable...

Injected fields are (in most cases) proxies that are instantiated. Even if the proxies are static in the sense that they are wired at bean creation time, they point to the current instance (the proxy method handler looks it up before calling the method). So nothing is injected on every/any method call but accessing the injected field (proxy) will always result in the current instance being invoked upon.

Elaborate on different kind of dynamic. What does that mean?

Section 5.4 of the final draft specification. (Client proxies.)

typo in PFD: client proxies are may be passivated

Already fixed.

It's a deliberate error since only $DEITY can make a perfect specification.

cool license plate: $DEITY

I am going to need to start writing some small Weld/CDI apps and/or running the examples thru the debugger in Eclipse to get a better understanding of this stuff (and stepping into the mnethods in the core classes). It's not sticking to me yet, sorry...

Stick breakpoints on all public methods of WeldBootstrap and the EL resolver, deploy the numberguess example and behold.

Gavin King wrote on Nov 07, 2009 21:06:
I'm guessing we will be able to roll the additional tests into the maintenance release.

You're reading my mind again ;-)

Pete Muir wrote on Nov 13, 2009 14:05:

Gavin King wrote on Nov 07, 2009 21:06:
I'm guessing we will be able to roll the additional tests into the maintenance release.

You're reading my mind again ;-)

Oh, I just realized why everyone thinks we do design behind closed doors - it's because we use telepathy to communicate ;-)