-
15. Re: 15 gotchas in seam
deanhiller2000 Nov 11, 2009 5:19 PM (in response to deanhiller2000)Arbi Sookazian,
thanks for shedding more light on the merge.....it is no wonder I love hibernates previous saveOrUpdate then as that is what I really want to do...I could care less about reattaching an entity to the conversation. -
16. Re: 15 gotchas in seam
kragoth Nov 12, 2009 12:21 AM (in response to deanhiller2000)
Arbi Sookazian wrote on Nov 11, 2009 01:07:
Don't forget (ab)use of the rendered attribute in JSF tags. DAllen covers this here:
http://www.jsfcentral.com/articles/speed_up_your_jsf_app_1.htmlThis is a very important one if you are trying to speed up your app. His research was quite eye opening. I am now much more careful about what I put in my rendered attributes!
-
17. Re: 15 gotchas in seam
deanhiller2000 Mar 4, 2010 7:19 PM (in response to deanhiller2000)adding one more in here. DO DO DO Run these tests before going to production
Test 1:
1. startup your server connected to database(do not hit a single web page yet!!!!)
2. pull the ehternet cable between db and server
3. hit a web page(many configurations end up waiting infinitely for db to respond)Test 2: (fails in oracle, passes in postgres)
1. startup your server connected to database
2. login and go to some page that can be refreshed without needing the database(and preferably with input)
3. crash the database with kill -9
4. refresh the page(it should work)
5. enter data into the page and submit(it should go to your error.xhtml page)On #5 Oracle ends up in infinite redirect.
BIG NOTE: On Test 2, if you use go to the login page after db is down and login, seam will only refresh the login page with Transaction failed even though I would prefer it to also go to errorDbDown.xhtml like my other pages...it is quite weird(seam 2.2.0.GA)
LASTLY, even though postgres worked fine on crashing, ONE MORE test everyone should run is this
Test 3.
1. After test 2, bring back up the database
2. make sure your website is still workingI have been having trouble with Test 3 in postgres/tomcat config but i thinkt that may be the connection pool is hibernates even though I keep trying to swap to c3p0 and failing.
later,
Dean -
18. Re: 15 gotchas in seam
deanhiller2000 Mar 4, 2010 7:21 PM (in response to deanhiller2000)adding one more in here. DO DO DO Run these tests before going to production
Test 1:
1. startup your server connected to database(do not hit a single web page yet!!!!)
2. pull the ehternet cable between db and server
3. hit a web page(many configurations end up waiting infinitely for db to respond)Test 2: (fails in oracle, passes in postgres)
1. startup your server connected to database
2. login and go to some page that can be refreshed without needing the database(and preferably with input)
3. crash the database with kill -9
4. refresh the page(it should work)
5. enter data into the page and submit(it should go to your error.xhtml page)On #5 Oracle ends up in infinite redirect.
BIG NOTE: On Test 2, if you use go to the login page after db is down and login, seam will only refresh the login page with Transaction failed even though I would prefer it to also go to errorDbDown.xhtml like my other pages...it is quite weird(seam 2.2.0.GA)
LASTLY, even though postgres worked fine on crashing, ONE MORE test everyone should run is this
Test 3.
1. After test 2, bring back up the database
2. make sure your website is still workingI have been having trouble with Test 3 in postgres/tomcat config but i thinkt that may be the connection pool is hibernates even though I keep trying to swap to c3p0 and failing.
later,
Dean -
19. Re: 15 gotchas in seam
shane.bryzak Mar 5, 2010 2:20 AM (in response to deanhiller2000)As per popular request, I've made this a sticky.
-
20. Re: 15 gotchas in seam
asookazian Mar 17, 2010 10:16 PM (in response to deanhiller2000)new article on dzone: Event-Driven MVC with JSF and JBoss Seam - Common Pitfalls: http://java.dzone.com/articles/event-driven-mvc-jsf-and-jboss
I don't necessarily agree with all the author's points in the above dzone article.
e.g. Scenario 1 - Placing controller initiation code in the facelets. I don't see anything wrong with this if you do it the right way. An example of the right way is showing h:commandButton which invokes an init() method and when the page reRenders, the button is not rendered.
e.g. Scenario 2 - Placing data retrieval methods in the facelets. What's wrong with this in the situation of populating a rich:dataTable via @DataModel List<T>? I guess this scenario is showing the problem with data retrieval (i.e. hitting the db) via rendered attribute. This actually is a practice or pattern to avoid generally in JSF apps.
-
21. Re: 15 gotchas in seam
asookazian Apr 12, 2010 10:50 PM (in response to deanhiller2000)Not sure if this is already posted but be careful the names of variables you use when you inject an EJB:
http://seamframework.org/Community/EJBAndInjection#comment123992
inject using interface name then Seam component name.
Example:
@Name("smartComponent") @Stateless public class SmartBean implements ISmart { ... }
inject SmartBean into DumbBean:
@Name("dumbComponent") @Stateless public class DumbBean implements IDumb { @In private ISmart smartComponent; }
-
22. Re: 15 gotchas in seam
sej Apr 14, 2010 12:02 AM (in response to deanhiller2000)Francisco Peredo wrote:
6). Do not validate simple stuff (numeric fields, regular expressions, dates, simple comparisions between fields, etc) using seam/jsf/richfaces validation, it is very slow, and your users will not like it, use jQuery, only use seam/jsf/richfaces validation for complex business logic stuff.
Are you talking only about a4j validation that occurs when tabbing off an input tag, or are you also including validation that occurs when clicking the submit button?
-
23. Re: 15 gotchas in seam
cash1981 Apr 22, 2010 2:05 PM (in response to deanhiller2000)Remember that if you have a component and you are using @Roles and you have listeners on that component, it will be called N + 1 (N being roles and 1 being @Name) times according to how many @Role names you use.
@Name("systemlogListener") @Transactional @Scope(ScopeType.SESSION) @Role(name="esbLogListener", scope=ScopeType.EVENT ) public class SystemlogListener implements Serializable { @Observer("storeSystemlog") public void saveSystemlog(String description, String category, String username, String org) { //Save some stuff } }
Then you call the event.
Events.instance().raiseEvent("storeSystemlog"); //This will now get called twice(!) because @Role will create a new component
-
24. Re: 15 gotchas in seam
luxspes Apr 23, 2010 8:44 PM (in response to deanhiller2000)
Steve Jagels wrote on Apr 14, 2010 00:02:
Are you talking only about a4j validation that occurs when tabbing off an input tag, or are you also including validation that occurs when clicking the submit button?Both, if you are only validating numeric fields, regular expressions, dates, simple comparisions between fields, etc using a4j:validation will result in a
this takes too much time
perception from your user, if you think it, it makes sense: why travel all the way to the server to know ifABC
is a number when you can do that in the client with javascript? -
25. Re: 15 gotchas in seam
henk53 May 8, 2010 7:33 PM (in response to deanhiller2000)
Both, if you are only validating numeric fields, regular expressions, dates, simple comparisions between fields, etc using a4j:validation will result in athis takes too much time
perception from your user, if you think it, it makes sense: why travel all the way to the server to know ifABC
is a number when you can do that in the client with javascript?Because the client can't be trusted?
-
26. Re: 15 gotchas in seam
kasper110382 May 15, 2010 10:29 PM (in response to deanhiller2000)I find that there are (at least) three gotchas pertaining to MANUAL flushing.
- Queries cause a flush either way so your
flush logic
might get interrupted in the middle of a conversation! - If you build up nested conversations your actions should investigate whether or not they are apart of a nested conversation to ensure that they don't call flush() on behalf of the parent-conversation.
- Other stuff depends on transactions and are not aware of MANUAL flushing, such as JMS. This means that your application will be out of sync because transaction doesn't
behave like they used to
.
I've covered them in more detail on my blog, kasper.eobjects.org.
- Queries cause a flush either way so your
-
27. Re: 15 gotchas in seam
asookazian May 15, 2010 11:38 PM (in response to deanhiller2000)
Francisco Peredo wrote on Nov 09, 2009 22:12:
How about:- Do not use EAR/EJBs if you want ZeroTurnaround, use WAR/POJOs. Read more
This is no longer true as of JRebel 3: https://community.jboss.org/wiki/JRebel3withSeam2xtutorial
-
28. Re: 15 gotchas in seam
asookazian May 15, 2010 11:43 PM (in response to deanhiller2000)
Kasper Sørensen wrote on May 15, 2010 22:29:
Queries cause a flush either way so yourflush logic
might get interrupted in the middle of a conversation!Simply use the setFlushMode() method to set to COMMIT as a workaround to this problem: http://java.sun.com/javaee/5/docs/api/javax/persistence/Query.html#setFlushMode%28javax.persistence.FlushModeType%29
The reason the MANUAL flush mode type is not in the JPA API is mostly political (Oracle's Mike Keith will not allow)...
-
29. Re: 15 gotchas in seam
deanhiller2000 May 18, 2010 7:32 AM (in response to deanhiller2000)
Queries cause a flush either way so your flush logic might get interrupted in the middle of a conversation!Odd, we usually do one query in the first transaction and it didn't flush our changes. we had to manually call flush. Also, once we were bootstrapped into the object model, we go from page to page to page to page never calling flush and then at the end call flush and we see all the updates go. We have log4jdbc running in production and even had an issue from two conversations on the same data where the second one got an exception as it had stale data(it did inserts at the end instead of updates)....fixed that by clearing the entityManager
BUT point being we have no updates to the db during a 5 to 10 question script the agents read to customers.We usually go from object to object(which results in queries to db and no flush)...I think there are cases where we do queries in the middle too....I guess I have just never seen that behavior yet in our cases.( not sure it is a gotcha)