[JBoss Seam] - selectItems and entities with inheritance
by adamw
Hello,
I have an abstract entity Feed and two entities that inherit from it, RemoteFeed and AggregatedFeed. I have the following on my page:
| <h:selectManyCheckbox value="#{aggregatedFeedMod.selectedFeeds}" layout="pageDirection">
| <s:selectItems var="feed" value="#{aggregatedFeedMod.availableFeeds}"
| label="#{feed.displayName}" />
| <s:convertEntity />
| </h:selectManyCheckbox>
|
where aggregatedFeedMod.availableFeeds is of type List < Feed >; the list contains entities of both subclasses.
Here's the exception I have when I try to display that:
| 15:52:06,089 ERROR [STDERR] Nov 26, 2007 3:52:06 PM com.sun.facelets.FaceletViewHandler handleRenderException
| SEVERE: Error Rendering View[/manage/aggregated/aggregated_edit.xhtml]
| java.lang.IllegalArgumentException: Cannot convert org.jboss.blog.model.AggregatedFeed@d19 of type class org.jboss.blog.model.AggregatedFeed to class org.jboss.blog.model.RemoteFeed
| at org.jboss.el.lang.ELSupport.coerceToType(ELSupport.java:358)
| at org.jboss.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
| at org.jboss.seam.el.SeamExpressionFactory.coerceToType(SeamExpressionFactory.java:70)
| at com.sun.faces.renderkit.html_basic.SelectManyCheckboxListRenderer.renderOption(SelectManyCheckboxListRenderer.java:275)
| at com.sun.faces.renderkit.html_basic.SelectManyCheckboxListRenderer.encodeEnd(SelectManyCheckboxListRenderer.java:146)
| at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:836)
| at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:279)
| at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:117)
| at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:812)
| at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:271)
| at com.sun.faces.renderkit.html_basic.GridRenderer.encodeChildren(GridRenderer.java:242)
| at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:812)
| at javax.faces.component.UIComponent.encodeAll(UIComponent.java:886)
| at javax.faces.render.Renderer.encodeChildren(Renderer.java:137)
| at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:812)
| at javax.faces.component.UIComponent.encodeAll(UIComponent.java:886)
| at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892)
| at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:592)
| at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
| at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:216)
| at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
| at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
| at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144)
| at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.shotoku.web.ResourcesFilter.doFilter(ResourcesFilter.java:183)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
| at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:44)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
| at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
| at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
| at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
| at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
| at java.lang.Thread.run(Thread.java:613)
|
I'm not quite sure if it's a Seam issue, or a JBoss EL/JSF RI issue.
--
Adam
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107766#4107766
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107766
18 years, 5 months
[JBoss Messaging] - Re: Messaging Timeout thread pool limits configuration
by amalcaraz
Sorry,
I have forgotten the unit test:
public class StressDeadLock {
| static final int MAX_MESSAGES = 4* 1000;
| static final int MAX_ROLLBACK_MESSAGES = 5;
| static final int DELAY_TIME = 60000;
| static final String HOST_NAME = "nostromo";
| static final String QUEUE_NAME = "/queue/QueueWithOwnRedeliveryDelay";
|
| @Test
| public void stressTest1() {
| InitialContext ctx = null;
| ConnectionFactory connectionFactory = null;
| Queue destination = null;
| Connection sdnConnection = null;
| Connection rcvConnection = null;
| Session sndSession = null;
| Session rcvSession = null;
| MessageProducer producer = null;
| MessageConsumer consumer = null;
|
| String body = "Message schedule test";
|
| try {
| Properties props = new Properties();
| props.put(Context.INITIAL_CONTEXT_FACTORY,
| "org.jnp.interfaces.NamingContextFactory");
| props.put(Context.PROVIDER_URL, HOST_NAME + ":1099");
| props.put("java.naming.factory.url.pkgs",
| "org.jboss.naming:org.jnp.interfaces");
| ctx = new InitialContext(props);
| connectionFactory = (ConnectionFactory) ctx
| .lookup("/ConnectionFactory");
| destination = (Queue) ctx.lookup(QUEUE_NAME);
|
| sdnConnection = connectionFactory.createConnection();
| sndSession = sdnConnection.createSession(false,
| Session.AUTO_ACKNOWLEDGE);
|
| rcvConnection = connectionFactory.createConnection();
| rcvConnection.start();
| rcvSession = rcvConnection.createSession(true,
| Session.SESSION_TRANSACTED);
|
| consumer = rcvSession.createConsumer(destination);
| producer = sndSession.createProducer(destination);
|
| long deliveryTime = System.currentTimeMillis() + DELAY_TIME;
| int msgCounter = 0;
| int rollbackCounter = 0;
|
| while (msgCounter < MAX_MESSAGES) {
| TextMessage msg = sndSession.createTextMessage(body);
| msg.setLongProperty(
| JBossMessage.JMS_JBOSS_SCHEDULED_DELIVERY_PROP_NAME,
| deliveryTime);
| producer.send(msg);
|
| msgCounter++;
| System.out.println("Sending " + msgCounter + "...");
| }
|
| while (consumer.receive(DELAY_TIME) != null) {
| if (rollbackCounter < MAX_ROLLBACK_MESSAGES) {
| rcvSession.rollback();
|
| rollbackCounter++;
| } else {
| rcvSession.commit();
| }
|
| msgCounter--;
| System.out.println("Pending for receive " + msgCounter + "...");
| }
|
| assertFalse(msgCounter > (-1 * rollbackCounter));
| } catch (Exception e) {
| fail(e.getMessage());
| } finally {
| if (consumer != null) {
| try {
| consumer.close();
| } catch (Exception e) {
| }
| }
|
| if (producer != null) {
| try {
| producer.close();
| } catch (Exception e) {
| }
| }
|
| if (sndSession != null) {
| try {
| sndSession.close();
| } catch (Exception e) {
| }
| }
| if (rcvSession != null) {
| try {
| rcvSession.close();
| } catch (Exception e) {
| }
| }
|
| if (rcvConnection != null) {
| try {
| rcvConnection.close();
| } catch (Exception e) {
| }
| }
|
| if (sdnConnection != null) {
| try {
| sdnConnection.close();
| } catch (Exception e) {
| }
| }
|
| if (ctx != null) {
| try {
| ctx.close();
| } catch (Exception e) {
| }
| }
| }
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107764#4107764
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107764
18 years, 5 months
[Messaging, JMS & JBossMQ] - Binding remote queue to local jndi is failed
by slogger
It is necessary for me to send message to remote queue. Queue must be predefined declaratively.
I step by example hear http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigAdminObject with some changes:
<server>
| <mbean code="org.jboss.resource.deployment.AdminObject"
| name="jca.test:name=Inbox">
| <attribute name="JNDIName">queue/Inbox</attribute>
| <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='jms-ra.rar'</depends>
| <attribute name="Type">javax.jms.Queue</attribute>
| <attribute name="Properties">
| java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
| java.naming.factory.url.pkgs=org.jnp.interfaces
| java.naming.provider.url=10.0.0.226:1099
| </attribute>
| </mbean>
| </server>
|
and found issue:
org.jboss.deployment.DeploymentException: No admin object metadata type=javax.jms.Queue ra=jboss.jca:service=RARDeployment,name='jms-ra.rar'
| at org.jboss.resource.deployment.AdminObject.startService(AdminObject.java:99)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
| at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
| at $Proxy0.start(Unknown Source)
| at org.jboss.system.ServiceController.start(ServiceController.java:417)
| at org.jboss.system.ServiceController.start(ServiceController.java:435)
| at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy39.start(Unknown Source)
| at org.jboss.deployment.SimpleSubDeployerSupport.startService(SimpleSubDeployerSupport.java:356)
| at org.jboss.deployment.SimpleSubDeployerSupport.start(SimpleSubDeployerSupport.java:127)
|
What's the matter?
May be am I wrong in principle?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107762#4107762
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107762
18 years, 5 months
[JBoss Messaging] - Messaging Timeout thread pool limits configuration
by amalcaraz
Hi all,
Do you know any way to configure 'Messaging Timeout' thread queue limits? (MaximumQueueSize, MaximumPoolSize)
I`m trying to run a unittest but the AS throws a cascade of exceptions like this (the thread queue is full):
18:37:15,609 ERROR [Log4jService$ThrowableListenerLoggingAdapter] Unhandled Throwable
| org.jboss.util.threadpool.ThreadPoolFullException: java.lang.RuntimeException: Pool is blocked
| at org.jboss.util.threadpool.BasicThreadPool.execute(BasicThreadPool.java:417)
| at org.jboss.util.threadpool.BasicThreadPool.runTaskWrapper(BasicThreadPool.java:192)
| at org.jboss.util.threadpool.BasicThreadPool.run(BasicThreadPool.java:212)
| at org.jboss.util.threadpool.BasicThreadPool.run(BasicThreadPool.java:206)
| at org.jboss.util.timeout.TimeoutFactory.doWork(TimeoutFactory.java:223)
| at org.jboss.util.timeout.TimeoutFactory.access$000(TimeoutFactory.java:41)
| at org.jboss.util.timeout.TimeoutFactory$1.run(TimeoutFactory.java:136)
I have update MessagingTimeoutFactory.java with:
private void createFactory()
| {
| BasicThreadPool threadPool = new BasicThreadPool("Messaging Timeout");
| threadPool.setMaximumQueueSize(Integer.MAX_VALUE);
| factory = new TimeoutFactory(threadPool);
| }
and the exceptions disapear.
This update has test purpouses only. In production environment it should be a configurable parameter in destinations-service.xml.
Is this feature available?
Thanks at all,
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107759#4107759
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4107759
18 years, 5 months
[Datasource Configuration]MIgration from Jboss 3.2 -> 4.2 FAILURE -> JMX/JNDI Transactions fail when EJBs Involved
by Stephen Davidson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings.
(Sorry for the resend -- sent from the wrong account originally, which
seems to have failed).
I have been told that it is proper behaviour that any attempt to create
and register a DataSource, using the JBoss DataSource and related
classes, from inside an EJB transaction fail. From what I've been able
to determine so far, there is are least two MBean calls that are not
supportable by or do not support 2-Phase commit, which the new
Transaction Manager in 4.2 requires.
Using the JBoss Classes in this is causing failures in 4.2, but worked
in 3.0/3.2. This is currently being MISIDENTIFIED as a
Specification/Configuration Issue. As I just mentioned, it appears to
be an issue with JBoss MBean/Transaction Manager interactions.
See for details, stack traces, logs, etc;
http://jira.jboss.com/jira/browse/JBAS-4998
http://jira.jboss.com/jira/browse/JBAS-5001
This is causing my Migration from JBoss 3.2 -> 4.2 to fail. I thought
that the way I opened the Second JIRA, it was clear that there was an
JBoss MBean/Transaction Manager incompatibility somewhere (obviously was
NOT clear!)
The Workarounds I have been given are flagged as 'Dangerous'. Is there
ANY way for the appropriate JBoss JMX Classes to be upgraded, so that
they work for the 2-Phase Transaction Manager , and can be called from
inside an EJB with active transactions??? As it is, the calls to the
MBeans are either failing, or I have to set
'AllowMultipleLastResource=True", which is a 'Dangerous Solution'.
(I don't know enough about the Transaction Manager or the MBeans
involved to do fix this myself, and under a deadline tight enough that
makes sitting down inside an unknown code base not a good idea).
Sorry about being a little repetitive, but this is blocking migration of
a major project from JBoss 3.2, and other than being told to set a
'dangerous' configuration option, I've not been able to get any
assistance yet on this matter.
- -Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHSt3gPtiPEDq7o8YRAsQyAKCqysG5d2kK5dxRRImlBuAcGh01WgCbBT7b
Ov2Koq3P3KHMLpmey/MBljA=
=SKCw
-----END PGP SIGNATURE-----
18 years, 5 months