[The Lizzard's corner] - New job
by goldgroup
Team Leader ? Cambridge UK
Excellent opportunity for a team leader to supervise a team of engineers and guide them from a technical perspective to design, implement and maintain Client ? Server based configuration and monitoring systems for my client?s cellular based products. The role also includes integration, developing units tests and development of the OMCR architecture.
Experience:
. Experience of JBOSS and CORBA
. Excellent OO Java software development skills including the ability to select and apply well-known OO design patterns.
. Experienced architectural designer for Linux based Client/Server systems
. Experienced in developing Java based GUI?s.
If you are interested and would like to know more about this role please e-mail at matthew(a)goldgroup.co.uk
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097761#4097761
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097761
18Â years, 8Â months
[JBoss Seam] - Again - CachedConnectionManager: closing connection form you
by amashtakov
Hi All,
I'm developing an application generated by seam-gen (Seam 1.2.1GA)
on JBOSS 4.0.5GA. The user opens his profile for editing backed by
conversation scoped bean within nested conversation and idles.
After ~10 min he makes changes and submits the form, which in turn
raises the exception. Here is commented trace:
|
| User opens profile form and click on "save"
|
| ....
|
| 2007-10-23 11:32:57,392 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] after phase: RENDER_RESPONSE(6)
| 2007-10-23 11:32:57,392 DEBUG [org.jboss.seam.core.Manager] Storing conversation state: 4
| 2007-10-23 11:32:57,392 DEBUG [org.jboss.seam.contexts.Lifecycle] After render response, destroying contexts
| 2007-10-23 11:32:57,392 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying business process context
| 2007-10-23 11:32:57,392 DEBUG [org.jboss.seam.contexts.Lifecycle] flushing server-side conversation context
| 2007-10-23 11:32:57,392 DEBUG [org.jboss.seam.contexts.Lifecycle] flushing session context
| 2007-10-23 11:32:57,392 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying event context
| 2007-10-23 11:32:57,392 DEBUG [org.jboss.seam.contexts.Lifecycle] <<< End web request
|
| After 8 mins Seam starts cleaning(?) process
|
| 2007-10-23 11:40:12,120 DEBUG [org.jboss.seam.contexts.Lifecycle] >>> Begin call
| 2007-10-23 11:40:12,120 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying business process context
| 2007-10-23 11:40:12,120 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying conversation context
| 2007-10-23 11:40:12,120 DEBUG [org.jboss.seam.contexts.Lifecycle] flushing server-side conversation context
| 2007-10-23 11:40:12,120 DEBUG [org.jboss.seam.contexts.Lifecycle] flushing session context
| 2007-10-23 11:40:12,120 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying event context
| 2007-10-23 11:40:12,120 DEBUG [org.jboss.seam.contexts.Lifecycle] <<< End call
| 2007-10-23 11:40:12,135 DEBUG [org.jboss.seam.contexts.Lifecycle] >>> Begin call
| 2007-10-23 11:40:12,135 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying business process context
| 2007-10-23 11:40:12,135 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying conversation context
| 2007-10-23 11:40:12,135 DEBUG [org.jboss.seam.contexts.Lifecycle] flushing server-side conversation context
| 2007-10-23 11:40:12,135 DEBUG [org.jboss.seam.contexts.Lifecycle] flushing session context
| 2007-10-23 11:40:12,135 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying event context
| 2007-10-23 11:40:12,135 DEBUG [org.jboss.seam.contexts.Lifecycle] <<< End call
|
|
| User makes changes and submits the form
|
|
| 2007-10-23 11:42:04,919 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] before phase: RESTORE_VIEW(1)
| 2007-10-23 11:42:04,919 DEBUG [org.jboss.seam.contexts.Lifecycle] >>> Begin web request
| 2007-10-23 11:42:04,934 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] after phase: RESTORE_VIEW(1)
| 2007-10-23 11:42:04,934 DEBUG [org.jboss.seam.core.Manager] Restoring conversation with id: 4
| 2007-10-23 11:42:04,934 DEBUG [org.jboss.seam.jsf.AbstractSeamPhaseListener] After restoring conversation context: ConversationContext(4)
| 2007-10-23 11:42:04,934 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] before phase: APPLY_REQUEST_VALUES(2)
| 2007-10-23 11:42:04,950 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] after phase: APPLY_REQUEST_VALUES(2)
| 2007-10-23 11:42:04,950 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] before phase: PROCESS_VALIDATIONS(3)
| 2007-10-23 11:42:04,997 DEBUG [model.AccountManager] _ctor
| 2007-10-23 11:42:05,075 INFO [STDOUT] Hibernate: select account0_.id_account as id1_265_, account0_.comments_account as comments2_265_, account0_.email_account as email3_265_, account0_.firstname_account as firstname4_265_, account0_.lastname_account as lastname5_265_, account0_.login_account as login6_265_, account0_.password_account as password7_265_ from .account account0_ where email_account=?
| 2007-10-23 11:42:05,465 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] after phase: PROCESS_VALIDATIONS(3)
| 2007-10-23 11:42:05,465 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] before phase: UPDATE_MODEL_VALUES(4)
| 2007-10-23 11:42:05,497 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] after phase: UPDATE_MODEL_VALUES(4)
| 2007-10-23 11:42:05,497 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] before phase: INVOKE_APPLICATION(5)
| 2007-10-23 11:42:05,497 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] after phase: INVOKE_APPLICATION(5)
| 2007-10-23 11:42:05,497 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] before phase: RENDER_RESPONSE(6)
| 2007-10-23 11:42:05,544 DEBUG [org.jboss.seam.jsf.SeamPhaseListener] after phase: RENDER_RESPONSE(6)
| 2007-10-23 11:42:05,544 DEBUG [org.jboss.seam.core.Manager] Storing conversation state: 4
| 2007-10-23 11:42:05,544 DEBUG [org.jboss.seam.contexts.Lifecycle] After render response, destroying contexts
| 2007-10-23 11:42:05,544 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying business process context
| 2007-10-23 11:42:05,544 DEBUG [org.jboss.seam.contexts.Lifecycle] flushing server-side conversation context
| 2007-10-23 11:42:05,544 DEBUG [org.jboss.seam.contexts.Lifecycle] flushing session context
| 2007-10-23 11:42:05,544 DEBUG [org.jboss.seam.contexts.Lifecycle] destroying event context
| 2007-10-23 11:42:05,544 DEBUG [org.jboss.seam.contexts.Lifecycle] <<< End web request
| 2007-10-23 11:42:05,590 INFO [org.jboss.resource.connectionmanager.CachedConnectionManager] Closing a connection for you. Please close them yourself: org.jboss.resource.adapter.jdbc.WrappedConnection@19d019d0
| java.lang.Throwable: STACKTRACE
| at org.jboss.resource.connectionmanager.CachedConnectionManager.registerConnection(CachedConnectionManager.java:290)
| at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:417)
| at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
| at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
| at org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.getConnection(InjectedDataSourceConnectionProvider.java:47)
| at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:417)
| at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
| at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
| at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1560)
| at org.hibernate.loader.Loader.doQuery(Loader.java:661)
| at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
| at org.hibernate.loader.Loader.doList(Loader.java:2144)
| at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2028)
| at org.hibernate.loader.Loader.list(Loader.java:2023)
| at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:393)
| at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338)
| at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
| at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
| at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
| at org.hibernate.ejb.QueryImpl.getSingleResult(QueryImpl.java:80)
|
| ...
|
Clicking on "save" invokes model.AccountManager SFSB with changes in Account entity (which is a member of backing bean)
I tried to experiment with hibernate.connection.release_mode parameter
in persistence.xml, but this doesn't help.
BTW, http://wiki.jboss.org/wiki/Wiki.jsp?page=WhatDoesTheMessageDoYourOwnHouse... suggests to turn "debug" attribute off for org.jboss.resource.connectionmanager.CachedConnectionManager
mbean, but this will just "hide" symptoms and will not solve the problem.
Does anyone experienced the same problem and have any workaround on that ?
Thank you in advance,
/Alexander
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097753#4097753
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097753
18Â years, 8Â months
[Installation, Configuration & DEPLOYMENT] - Re: Overriding universal classloader, JBoss 4.2.1GA
by jaikiran
"jimpo991" wrote :
| I still don't understand why all this results in a ClassCastException about FullTextIndexEventListener. If my war uses the hibernate jars from WEB-INF, and they don't contain org.hibernate.search package, where does the classcastexception come from?
Valid question. I hadn't completely got an answer to that yesterday so i had intentionally left out the explanation for the classcast from my earlier post. But now, after going through the Hibernate Annotations code and adding some log statements and enabling verbose class logging, i guess i understand what the issue is. Let me try to put it here. Let's consider the case where you did NOT place the hibernate-search.jar file in the WEB-INF/lib of your application:
1) Where in the code does this classcast occur- The name of the class where this happens is AnnotationConfiguration.java (which is part of the hibernate-annotationsxxx.jar). The lines of the code are (just copied the relevant part here - see the line marked in bold):
try {
| searchEventListenerClass = ReflectHelper.classForName(
| "org.hibernate.search.event.FullTextIndexEventListener",
| AnnotationConfiguration.class );
|
| }
| ...//some code here
| PostInsertEventListener[] listeners = getEventListeners().getPostInsertEventListeners();
| newListeners[length-1] = (PostInsertEventListener) searchEventListener;
| ...//some more code here
|
|
So when the FullTextIndexEventListener is being cast to PostInsertEventListener, the classcast is being thrown. But looking at the FullTextIndexEventListener class definition, it infact does implement this interface:
public class FullTextIndexEventListener implements PostDeleteEventListener, PostInsertEventListener,
| PostUpdateEventListener, Initializable {
|
As you have been wondering, since the FullTextIndexEventListener is available ONLY in the hibernate-annotations.jar file present in the server/lib folder, how could it be that the FullTextIndexEventListener be loaded by 2 different classloaders. A bit of verbose class logs revealed that it was not the FullTextIndexEventListener that was loaded by different classloaders. It turned out that the PostInsertEventListener was being loaded by different classloaders. Here's the reason - The PostInsertEventListener is part of the hibernate (core) jar. The hibernate jar is present in the server/lib folder as well as the application's WEB-INF/lib folder. The PostInsertEventListener was once loaded by the application specific classloader. Then when the following code was executed
searchEventListenerClass = ReflectHelper.classForName(
| "org.hibernate.search.event.FullTextIndexEventListener",
| AnnotationConfiguration.class );
the FullTextIndexEventListener (present in hibernate-annotations.jar in server/lib) got loaded by the parent classloader since it was not present in your application's WEB-INF/lib folder. While loading this class, the server also loaded (again) the PostInsertEventListener (remember the FullTextIndexEventListener implements this interface) , this time using the classloader which loaded FullTextIndexEventListener - which turns out to be the parent classloder (since the parent classloader was used, it picked up this interface from the hibernate3.jar present in the server/lib folder and not the hibernate-3.2.5.jar present in the WEB-INF/lib of your application). Ultimately, the PostInsertEventListener was loaded by 2 different classloaders through the hibernate3.jar (in server/lib) and hibernate-3.2.5.jar (in WEB-INF/lib). This resulted in the classcast.
Adding the hibernate-search.jar to WEB-INF/lib solves the problem because, the FullTextIndexEventListener (and eventually the PostInsertEventListener ) will be loaded by the application specific classloader instead of the parent classloader.
Makes sense?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097752#4097752
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097752
18Â years, 8Â months