[JBoss Seam] - s:selectItems changes in 2.0.0BETA1?
by jimk1723
It looks like there were some changes to s:selectItems that broke functionality that worked in Seam 1.2.
I had a panel that displayed two selectManyListboxes for adding and removing things from an entity - one box displayed the list of available items, the other displayed the list of assigned items. In Seam 1.2 this worked, after the update to 2.0.0 it appears that the listbox backed by the entity query is only updated during the Process Validations phase (or Apply Request Values if I set immediate = true.)
The net effect is that the list of "available" things doesn't reflect the state of the entity since it was updated before the action handler.
What should I change so that #{bucketHome.availableThings} is updated *after* the event actions are executed - so the result list doesn't include the Things that were just added or removed?
Here's my relevant JSF:
| <s:decorate id="assignThings" template="layout/edit.xhtml">
| <ui:define name="label">Assign Things!</ui:define>
| <table>
| <thead>
| <tr>
| <th>Available Things</th>
| <th> </th>
| <th>Assigned Things</th>
| </tr>
| </thead>
| <tbody>
| <tr>
| <td>
| <h:selectManyListbox id="things1" value="#{bucketHome.thingsToAdd}" size="10">
| <s:selectItems var="thing" value="#{bucketHome.availableThings}" label="#{thing.name}" />
| <s:convertEntity />
| </h:selectManyListbox>
| </td>
| <td>
| <div>
| <h:commandButton value=">" action="#{bucketHome.addThings}" />
| </div>
| <div>
| <h:commandButton value="<" action="#{bucketHome.removeThings}" />
| </div>
| </td>
| <td>
| <h:selectManyListbox id="things2" value="#{bucketHome.thingsToRemove}" size="10">
| <s:selectItems var="thing" value="#{bucketHome.instance.things}" label="#{thing.name}" />
| <s:convertEntity />
| </h:selectManyListbox>
| </td>
| </tr>
| </tbody>
| </table>
| </s:decorate>
|
The logic is all in the EntityHome:
| List<Thing> thingsToAdd;
|
| List<Thing> thingsToRemove;
|
| public void addThings() {
| for (Thing thing : thingsToAdd) {
| getInstance().getThings().add(thing);
| }
| }
|
| public void removeThings() {
| for (Thing thing : thingsToAdd) {
| getInstance().getThings().remove(thing);
| }
| }
|
| public List<Thing> getThingsToAdd() {
| return thingsToAdd;
| }
|
| public void setThingsToAdd(List<Thing> thingsToAdd) {
| this.thingsToAdd = thingsToAdd;
| }
|
| public List<Thing> getThingsToRemove() {
| return thingsToRemove;
| }
|
| public void setThingsToRemove(List<Thing> thingsToRemove) {
| this.thingsToRemove = thingsToRemove;
| }
|
| public List getAvailableThings() {
|
| if (getInstance() != null && getInstance().getThings() != null
| && getInstance().getThings().size() > 0) {
| return getEntityManager()
| .createQuery(
| "SELECT thing FROM Thing thing WHERE thing NOT IN (:things)")
| .setParameter("things", getInstance().getThings())
| .getResultList();
| } else {
| return getEntityManager().createQuery(
| "SELECT thing FROM Thing thing").getResultList();
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061427#4061427
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061427
19Â years
[Installation, Configuration & DEPLOYMENT] - Why does JBoss rewrite web.xml
by DjHitItUp
I have noticed that 'touch' on the web.xml does not redeploy the web application due to JBoss rewriting the web.xml file.
web.xml (original):
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd">
<!-- The Welcome File List -->
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<!-- Servlets -->
<servlet-name>TestWebService</servlet-name>
<servlet-class>com.company.department.ws.TestWebService</servlet-class>
<!-- Servlet Mappings -->
<servlet-mapping>
<servlet-name>TestWebService</servlet-name>
<url-pattern>/webservice/TestWebService</url-pattern>
</servlet-mapping>
</web-app>
When JBoss is restarted the web.xml is rewritten to the below:
<web-app version='2.4' xmlns='http://java.sun.com/xml/ns/j2ee' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:schemaLocation='http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd'>
<!-- The Welcome File List -->
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<!-- Servlets -->
<servlet-name>TestWebService</servlet-name>
<servlet-class>org.jboss.ws.integration.jboss42.JBossServiceEndpointServlet</servlet-class>
<init-param>
<param-name>ServiceEndpointImpl</param-name>
<param-value>com.company.department.ws.TestWebService</param-value>
</init-param>
<!-- Servlet Mappings -->
<servlet-mapping>
<servlet-name>TestWebService</servlet-name>
<url-pattern>/webservice/TestWebService</url-pattern>
</servlet-mapping>
</web-app>
My question is why does JBoss rewrite the web.xml. If it must rewrite the web.xml shouldn't it do this and leave in memory (JVM) and not overwrite the original web.xml? Because of this I have to have an original web.xml written as another file (like web.xml.org) and have an ant task to copy the original web.xml (web.xml.org) to web.xml. It's just bothersome. Is there a quicker way to redeploy an exploded war that I do not know?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061424#4061424
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061424
19Â years
[JBoss jBPM] - Re: Concurrent Processing using Fork in synchronous manner
by estaub
Ronald,
>> Examples often do 'wrong' things..
I think you're suggesting that this isn't a real use case. I think I see your point -- without any asynchronous behavior, the two branches are serialized and so might as well be modeled as a straight line.
But imagine an actionhandler that may enter a wait state (not signal, but wait for an external signal) or not, dependent on some condition. In this case, a fork might make sense, but in some conditions would fail as described.
In general, I think these kinds of problems should be fixed, regardless of whether it seems to be a real-world case. ["These kinds of problems" is vague, and vulnerable to reductio ad absurdum.] They reduce confidence in JBPM and give it a "bad taste". If it seems broken, it might as well be broken.
>> What is the issue here is that there is no wait state where the process is persisted, so everything happens in one 'transaction'... and both update the same token...
Agreed. A good fix is complex... this is another of those cases where the correct fix will depend on whether the deployment is single-threaded, multi-threaded/single-server, or multi-threaded/multi-server. I wrote a fix that queues up a job to do the parent-token work in Join... but it's only a good fit for one or two of those three deployment scenarios.
-Ed Staub
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061423#4061423
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061423
19Â years
[Messaging, JMS & JBossMQ] - Re: connection factory to remote queue
by dlgrasse
Thank you for the help. I had actually seen that one, too, and made some initial attempts with it. The couple of days I've spent on this, and the permutations of config values attempted, have me forgetting everything I've tried.
Here's what I'm getting with trying the technique from the page mentioned:
setup)
anonymous wrote : - running JBoss 4.0.3sp1
| - local machine web app attempting to connect to "queue/EventQueue" on remote machine < queuehost >
| - added "remote-queues-service.xml" file to local 'deploy' directory
| - added "tx-connection-factory" tag to 'jms/jms-ds.xml' file
| - not using security realm
1) tried it with almost verbatim what they show
remote-queues-service.xml:
<server>
| <mbean code='org.jboss.jms.jndi.JMSProviderLoader'
| name='jboss.mq:service=JMSProviderLoader,name=JMSProvider'
| >
| <attribute name='ProviderName'>DefaultJMSProvider</attribute>
| <attribute name='ProviderAdapterClass'>org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
| <attribute name='QueueFactoryRef'>java:/XAConnectionFactory</attribute>
| <attribute name='TopicFactoryRef'>java:/XAConnectionFactory</attribute>
| <attribute name='Properties'>
| java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
| java.naming.factory.url.pkgs=org.jnp.interfaces
| java.naming.provider.url=<queuehost>:1099
| </attribute>
| </mbean>
| </server>
|
jms-ds.xml:
<tx-connection-factory>
| <jndi-name>EventJmsXA</jndi-name>
| <xa-transaction/>
| <adapter-display-name>JMS Adapter</adapter-display-name>
| <config-property name='SessionDefaultType' type='java.lang.String'>javax.jms.Queue</config-property>
| <config-property name='JmsProviderAdapterJNDI' type='java.lang.String'>java:/DefaultJMSProvider</config-property>
| </tx-connection-factory>
|
code binds to connection factory: EventJmsXA
result:
Trying to install an already registered mbean: jboss.mq:service=JMSProviderLoader,name=JMSProvider
2) so i try with another name in the files:
remote-queues-service.xml:
<server>
| <mbean code='org.jboss.jms.jndi.JMSProviderLoader'
| name='jboss.mq:service=JMSProviderLoader,name=EventJMSProvider'
| >
| <attribute name='ProviderName'>EventJMSProvider</attribute>
| <attribute name='ProviderAdapterClass'>org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
| <attribute name='QueueFactoryRef'>java:/XAConnectionFactory</attribute>
| <attribute name='TopicFactoryRef'>java:/XAConnectionFactory</attribute>
| <attribute name='Properties'>
| java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
| java.naming.factory.url.pkgs=org.jnp.interfaces
| java.naming.provider.url=<queuehost>:1099
| </attribute>
| </mbean>
| </server>
|
jms-ds.xml:
| <tx-connection-factory>
| <jndi-name>EventJmsXA</jndi-name>
| <xa-transaction/>
| <adapter-display-name>JMS Adapter</adapter-display-name>
| <config-property name='SessionDefaultType' type='java.lang.String'>javax.jms.Queue</config-property>
| <config-property name='JmsProviderAdapterJNDI' type='java.lang.String'>java:/EventJMSProvider</config-property>
| </tx-connection-factory>
|
result:
javax.naming.NameNotFoundException: EventJmsXA not bound
| <stacktrace>
|
| --- MBeans waiting for other MBeans ---
| ObjectName: jboss.jca:service=TxCM,name=EventJmsXA
| State: CONFIGURED
| I Depend On:
| jboss.jca:service=ManagedConnectionPool,name=EventJmsXA
| jboss.jca:service=CachedConnectionManager
| jboss:service=TransactionManager
| Depends On Me:
| jboss.jca:service=ConnectionFactoryBinding,name=EventJmsXA
|
| ObjectName: jboss.jca:service=ManagedConnectionPool,name=EventJmsXA
| State: CONFIGURED
| I Depend On:
| jboss.jca:service=ManagedConnectionFactory,name=EventJmsXA
| Depends On Me:
| jboss.jca:service=TxCM,name=EventJmsXA
|
| ObjectName: jboss.jca:service=ManagedConnectionFactory,name=EventJmsXA
| State: CONFIGURED
| I Depend On:
| jboss.jca:service=RARDeployment,name=''
| Depends On Me:
| jboss.jca:service=ManagedConnectionPool,name=EventJmsXA
|
| ObjectName: jboss.jca:service=ConnectionFactoryBinding,name=EventJmsXA
| State: CONFIGURED
| I Depend On:
| jboss.jca:service=TxCM,name=EventJmsXA
|
| --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
| ObjectName: jboss.jca:service=RARDeployment,name=''
| State: NOTYETINSTALLED
| Depends On Me:
| jboss.jca:service=ManagedConnectionFactory,name=EventJmsXA
|
trying it with code binding to java:/EventJmsXA yields the same results.
So my problem is that I try several variations on the basic documentation but cannot get it working. Am I just missing some simple detail?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061421#4061421
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061421
19Â years