JBossDeveloper

Actually this guy fixes about a third of my Seam problems and he does not even use Seam!

Forum Troll, now that's ugly.  Perhaps absurd and slovenly, like a gangster with rabies.

How about Wilma the Seamstress?  Sounds cuter and more discotheque, no?

Why would they recruit me if I've been doing this for free for months?

Maybe I should stop posting on here and start studying biogerontology or similar?  :)

All hail EE 6.

Arbi Sookazian wrote on Aug 24, 2009 23:47:

Forum Troll, now that's ugly.  Perhaps absurd and slovenly, like a gangster with rabies.

I don't care what I am called as long as I have food on table and a horse in paddock for the house thing and I can code in something decent.

Why would they recruit me if I've been doing this for free for months?

I was by ICEfaces.
You get noticed on Forums especially if you are polite and helpful and knowledgeable.

Who knows..

p.s. I have NO sway with JBoss boys matey!

p.p.s. I even got mentioned in a Seam book preface and I didn't know till someone pointed it out to me!

From what I understand Seam 3 will drop the Seam 2 core and will be based on the JSR299 Core.

CORE CORE CORE

Then the seamsters will add the usual seam stuff you would expect like pdf, jbpm, jpdl, etc. etc. from the existing seam code pool.

So the seamsters are hopefully working flat out on what will the new seam core.

We will be transmuted (kicing and screaming) into using new (but familiar) Annotations (allegedly by an upgrade path).

As JSR299 will be part of J636E then the code quality will have to be quite high so don't expect this to happen quickly!

The END result is you will be very marketable as SUN/Oracle/etc. will be pushing a darn good technology that you know quite well.

So if you see not a lot happening at the moment... well...

This could all be a load of poop though.. it's not like Gav or anyone else is telling us much is it!

...

How can you tell the Amway rep on his weding night?
He is the one sitting on the end of the bed all night telling her how great it's going to be...

:)

Over the years (almost 5 years now since 3.2.7.GA), I've made a lot of disparaging comments about JBoss Inc. and JBoss AS and Seam, etc.  JBoss marketing, in particular, is very poor.  Microsoft truly rules in that arena.

I'm pretty sure I've been blacklisted somehow by JBoss but that's ok.  There are several other very worthy candidates in this forum to be the troll...

Unfortunately, I have a feeling I will not be working on Seam projects very soon.  And as a direct result, my help/comments will most likely be posted on other forums for other technology stacks/frameworks.

Arbi,

I have never worked on a Seam project for anyone else.
I have never worked on a JSF project.
I have never been paid for working on any of my seam projects.

I now have clients paying since starting Seam consultancy.

No reason you cant play in your own time.

You will be missed as it shown by the obvious support you have got in the forums.

Tony Herstell wrote on Aug 25, 2009 01:33:

I now have clients paying since starting Seam consultancy.

No reason you cant play in your own time.

You will be missed as it shown by the obvious support you have got in the forums.

I would say very lucky you!  Of course, if you start your own consulting company, you are free to use whatever technology you like to implement solutions for your customers internal or external-facing web applications.

Unfortunately, that requires a huge investment of time, planning, communication and effort (and money).  I have been down that path and registered a service mark with uspto.gov for INFODIMENSION consulting a few years ago.  And I actually bought a $2000 MSDN Universal subscription to do .NET development.  Now I'm here.  The marketing aspect of a consulting business is a killer for most tech folks.

I think it would be very cool to be a computer programming professor in some shape or form for the following reasons:

1) no competition (or little anyways)
2) no (day-to-day) boss
3) hang out with young crowd
4) lots of research

list goes on... too bad California is bankrupt, you get a master's degree and then no jobs in public universities or community colleges.

Anyways, I have not even heard of the JBoss seamsters visiting SoCal for JBUG sessions.  Do we even have one out here in LA?  It's a huge city!  I tried to sign up for advanced Hibernate training out here and no classes were available, it's pretty bad with Redhat...

I've spent 2 years now working on a medium sized business application and we utilise SEAM but, not as a single tier solution.

SEAM's ability to make using JSF a whole lot easier is GREAT! However, making an application single tiered is difficult. I've heard arguments from both camps as to whether is a good idea or not, so my guess is that it really depends on the application.

In my environment when our Hibernate Entities reach the SEAM layer they are detached and SEAM has no knowledge or our database or Hibernate. This works well for us. And maybe jboss/redhat should not try to market SEAM as a single tier approach. Sure its an option, but it is not a necessity. I know some of the architects I've talked to get pretty concerned when they hear single tier.

I'm still on the fence as to whether I would ever recommend a SEAM approach again. Some things in SEAM are really good, others are just horrible. I spent a long time learning how SEAM works so that I could write my own infrastructure over the top of SEAM to make it work the way we needed it to. (Navigation -> passing params between conversations -> implemented our own concept of nested conversations, etc. - all this with compile time safety not string bindings). So it looks like SEAM does the really complex things REALLY well. But the simple things sometimes leave me going :O Why is this so painful!. And although SEAM takes away the need for all the ugly JSF xml it still requires a lot of navigation xml (unless you write your own navigation framework like we did). XML is not cool.... ever :P (Ok, that's just my opinion :P). String binding sucks and should be avoided as much as possible. (Allow Injection by type instead of name already :P)

I think it will be interesting to see if SEAM/Web Beans become mainstream. I think there is great potential, but I still feel as though SEAM becomes inflexible in larger applications and when you hit that point you have to go back and write your own infrastructure around it anyways.

1) It's Seam, not SEAM.  Sorry, couldn't help it.

2) What do you mean Seam apps are single-tiered?  Client/server was based on the 2-tier architecture (fat client and db).  Web development is typically n-tiered (usually 3 or more), no?  So you have the presentation layer (JSF) with backing beans (EJB or JavaBean components), the business layer (EJB or JavaBean components), the persistence layer (DAO) and the data model (JPA entity classes).

Seam is flexible architecturally in that it does not enforce layers and certain API/classes like Spring.  In Spring MVC, for example, there is a front controller component, the DispatcherServlet.  Then you must use a Controller class like AbstractController which returns a ModelAndView object.  In JSF/Seam, there is no front controller equivalent and it seems more natural than Spring MVC.

Just because you can glue JSF with EJB does not necessarily mean that you should collapse all the layers completely.  And it also does not mean you must have a DAO layer if you're writing a basic CRUD app that does not have a lot of business logic, but mostly persistence logic.  Even Rod Johnson, in his famous book J2EE without EJB, does not mandate a DAO layer for simple CRUD apps with little business logic.

3) I think the success of Web Beans is intrinsically tied to the success of the EE 6 platform (specifically, JPA 2.0, JSF 2.0, EJB 3.1)

4) JSF/Seam needs a major performance boost/optimization as DAllen outlined in the jsfcentral.com series.  The render attribute in JSF tags is a disaster due to the JSF life cycle and the seemingly unknown number of times a getter method may be called.  Perhaps Wicket and Seam/Web Beans requires more exploration...

1) I use SEAM to make it obvious that I'm talking about the product not the english word seam. Sorry, couldn't help it :P

I'm pretty keen to try the Wicket/Seam (spelt it like that for you :P) approach someday.

Regards the single tier comments.... maybe single tier wasn't quite what I should have said. I'm really refering to the idea of an extended persistence context. I'm sure it can work great but so far I've only seen huge amounts of problems. Anyways, I don't have time to give details atm... (I should be working :P)

Tim Evers wrote on Aug 25, 2009 05:16:


Regards the single tier comments.... maybe single tier wasn't quite what I should have said. I'm really refering to the idea of an extended persistence context. I'm sure it can work great but so far I've only seen huge amounts of problems. Anyways, I don't have time to give details atm... (I should be working :P)

Oh, stop teasing.  Please explain (or in another thread?)  SMPC and Hibernate manual flush is the dynamic duo!  The application tx (or atomic conversation) is the pinnacle of Seam's persistence support.

As far as preventing LIEs, the extended PC is critical (otherwise, you're stuck with weaker solutions like OSIV like in Spring/Hibernate).

The idea of an application transaction with optimistic semantics, and the realization that existing
frameworks based around a stateless architecture could not provide effective management of
extended persistence contexts. (The Hibernate team is truly fed up with copping the blame for
LazyInitializationExceptions, which are not really Hibernate's fault, but rather the fault of
the extremely limiting persistence context model supported by stateless architectures such as
the Spring framework or the traditional stateless session facade (anti)pattern in J2EE.)

from the Seam ref doc.

Using an open session up in the presentation layer to avoid LIEs is one of the worst arguments for Seam I could think of. Sure, the community complains about it being Hibernate's fault or whatever. So, let me ask you something. Who are these people that get upset about these exceptions? These are the people that are NOT writing large business applications. If you have the experience in writing any sort of decent size application then you KNOW what a LIE is and you know exactly how to fix it. People who are new programmers or people who don't read documentation or people who are still learning to program are the community who complain about these exceptions. Now apart from my opinion of that community, there's an even bigger flaw with allowing unitialised proxies to be lazy initialised in the presentation layer. Doing this leads to potentially large performance issues. If you keep your session open and allow all your proxies to be lazy initialised you are at some stage going to get into the n+1 query situation. Now I go back to my original argument. If your programmer does not know how to solve a LIE then they are not going to be looking at the query logs to see how many SQL statements are being issued. And unless you are concerned about your performance or you are running on a large dataset you wont even notice until you roll out to a big dataset. Now you have to spend days/weeks going through your system fixing up what you would have already known if the proxies didn't get initialised for you.

I guess what I'm saying is just because Seam makes something easier to use, doesn't make it better. I'm by no means an experienced programmer, but I know enough to realise the value of LIEs.

Sure, smaller apps the SMPC would be a dream! Seriously, if I was writing a small app on the side I would use it. It is fast, easy and very painless. But the risks are too great in a larger application.

Ok, so seeings as I'm wasting time responding I'll answer my point about the SMPC causing problems (apart from what I've just mentioned).
They system I'm working on at the moment is probably unusually complicated and thus warps my opinion of the whole SMPC + manual flush concept. But there are simple things like, A -> (Collection)B. So Entity A has a collection of Bs(cascaded to). I query out A and fetch the B collection. now I want to sort this list so I use a Collections.sort(a.getBs). I havn't changed any values on the entity. But now if I call a flush A will get an update issued on it. So my audit code will say user XX changed entity A. But they didn't. This is not a good example. But what I'm trying to say is the idea of SMPC working for everyone's application is idealistic and shortsighted. The decision to not use SMPC was made some 2 years ago and I would have to go through a few of our system's features to remember what all the reasons were. Things like the fact that we have a Batch interface as well as web interface makes it much harder to keep our application purely Seam. Infact I'm not sure how we could even do that. (Web interface must not be available at night while batch process runs etc). And probably one of the more fundamental problems I can see is that testing a Seam application is somewhat harder. (Yes I've read the doco and tried it and yeah it sorta works but not exactly how the application works so, never really quite a 100% satisfaction there) Whereas our services (Spring Beans) can be tested by straight JUnit tests and their behaviour is exactly the same as if the application was running. Other things like the fact that if I make a change to an attached entity then any queries on that table I do will cause that entity to be flushed. But what if I'm not wanting to flush just yet? My prepersist validation fails and ... you get the idea. I'm sure I don't undestand the full power of SMPC because I don't use it, but these are things that I struggle with. How can I be sure of when things are going to happen. Because in our application that is important.

(Like I said earlier though, I think SMPC + manual flush is probably application specific.)
And yes, my attempt at explaining my problems with SMPC is pretty bad but it's not like I've been writing a book about it :P.

Perhaps you have some valid points (although honestly, I'm hoping you're wrong in most cases).

Again, from chapter 7 of the Seam ref doc:

The Hibernate team is truly fed up with copping the blame for LazyInitializationExceptions, which are not really Hibernate's fault, but rather the fault of the extremely limiting persistence context model supported by stateless architectures such as the Spring framework or the traditional stateless session facade (anti)pattern in J2EE.

The key to avoiding LIEs is to keep the persistence context (or Hibernate Session), open for as long as is required for your conversation.

So in JSR220, there are two types of PCs: one is transaction-scoped, the other is component-scoped.  SMPC is conversation-scoped and is critical for a stateful framework like Seam.  That means when you use:

@In 
private EntityManager entityManager;

you're injecting a conversation-scoped extended PC (SMPC) which is available and open for the duration of the LRC.  This means no LIEs for the duration of the conversation.  So what's bad about that?

Now whether or not it makes a difference if you're using SMPC with a small or medium or large Seam app, I'm not sure how that matters.  Is there more overhead with SMPC and large apps or what?  And even if there is, you should consider using Hibernate 2nd level cache and query cache as performance optimizations.

This is likely the first time I've heard anybody complain about SMPC on this forum.  Although I have personally only worked on small Seam projects so I wouldn't know anyways.

I'd like to know what the official response to this is...

Like I was trying to say the SMPC is fine as long as the programmer understands what that means.

Many programmers may not realise that by using a SMPC (open for entire conversation) that they may be issuing hundreds if not thousands of unnecessary SQL queries. If you force your application to load the appropriate graph (by letting LIEs bubble up and error the application) then you force the programmer to pay attention to the object graph he/she is trying to work with. Otherwise you will end up with cartesian products being lazy initialised without you realising. And I agree that in a smaller application this may not be a big deal. And on certain databases it may not be an issue. But there are some databases that will not scale nicely when you have multiple users all sending thousands of SQL statements at the same time. So what this means is that eventually when you have to go back and look at the performance issues created by using a SMPC. Then you will end up writing your fetch queries just as you would have when you weren't using a SMPC.

SMPC is a great tool for rapid development, prototyping and small apps. But when you start issuing n+1 queries due to lazy initialisation it just wont work in a large app.