[JBoss Seam] - Using page parameters instead of Seam remoting
by asookazian
I'm currently using Seam remoting to pass facelet dataTable variables to a SFSB.
| function setNoteData(rowIndex, colName, siteId, employeeNumber, icomsAccountApproved, securityLevelApproved, adjustmentLimitApproved) {
| Seam.Component.getInstance("noteAction").setNoteData(rowIndex, colName, siteId, employeeNumber, icomsAccountApproved, securityLevelApproved, adjustmentLimitApproved);
| }
When I placed a debug stop in Eclipse on the first line of the @WebRemote method and ran the test case, I get the following exception after I step over the first line of code:
Caused by java.lang.IllegalStateException with message: "could not acquire lock on @Synchronized component: noteAction"
What does this mean exactly and why does it happen? Is it normal to not be able to place debug stops in a @WebRemote method? (sorry in advance if this is a stupid question).
I'd prefer to use Seam page parameters to transfer these variables to the SFSB. I'm assuming that is the preferred method of data transfer in the PAGE or REQUEST scope when user submits the form. I've read the Seam ref pdf starting on page 78. Are there any good examples on how to implement this (e.g. the Seam distro examples)?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112025#4112025
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112025
18 years, 4 months
[JBoss jBPM] - Re: New jBPM Getting Started Documentation
by bezpal
What this may mean? and how to fix it?
It happens when I'm trying to open gpd.xml
There was a problem adding adapter factories
loader constraint violation: when resolving method "org.eclipse.wst.xml.core.internal.modelquery.ModelQueryUtil.getModelQuery(Lorg/w3c/dom/Document;)Lorg/eclipse/wst/xml/core/internal/contentmodel/modelquery/ModelQuery;" the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current class, org/eclipse/wst/xml/ui/internal/DOMObserver, and the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) for resolved class, org/eclipse/wst/xml/core/internal/modelquery/ModelQueryUtil, have different Class objects for the type org/w3c/dom/Document used in the signature
Thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112016#4112016
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112016
18 years, 4 months
[JBossCache] - Really important problem with JDBCCacheLoader
by jorgemoralespou_2
Hi,
We have a system, where we test it with Oracle9i and Mysql5, with these configuration.
| <server>
|
| <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar" />
|
|
| <!-- ==================================================================== -->
| <!-- Defines TreeCache configuration -->
| <!-- ==================================================================== -->
|
|
| <mbean code="org.jboss.cache.TreeCache"
| name="jboss.cache:service=SOMServicesProvisioningCache">
|
| <depends>jboss:service=Naming</depends>
| <depends>jboss:service=TransactionManager</depends>
| <depends>
| jboss.jca:name=jdbc/somservices,service=DataSourceBinding
| </depends>
|
| <attribute name="TransactionManagerLookupClass">
| org.jboss.cache.JBossTransactionManagerLookup
| </attribute>
|
| <!--
| Isolation level : SERIALIZABLE
| REPEATABLE_READ (default)
| READ_COMMITTED
| READ_UNCOMMITTED
| NONE
| -->
| <attribute name="IsolationLevel">NONE</attribute>
|
| <!--
| Valid modes are LOCAL
| REPL_ASYNC
| REPL_SYNC
| INVALIDATION_ASYNC
| INVALIDATION_SYNC
| -->
| <attribute name="CacheMode">REPL_SYNC</attribute>
|
| <!-- Just used for async repl: use a replication queue -->
| <attribute name="UseReplQueue">false</attribute>
| <!-- Replication interval for replication queue (in ms) -->
| <attribute name="ReplQueueInterval">0</attribute>
| <!-- Max number of elements which trigger replication -->
| <attribute name="ReplQueueMaxElements">0</attribute>
|
| <!-- Name of cluster. Needs to be the same for all clusters, in order
| to find each other -->
| <attribute name="ClusterName">
| SOMServicesProvisioning-Cluster
| </attribute>
|
| <!-- JGroups protocol stack properties. Can also be a URL,
| e.g. file:/home/bela/default.xml
| <attribute name="ClusterProperties"></attribute>
| -->
|
| <attribute name="ClusterConfig">
| <config>
| <!-- UDP: if you have a multihomed machine,
| set the bind_addr attribute to the appropriate NIC IP address, e.g bind_addr="192.168.0.2" -->
| <!-- UDP: On Windows machines, because of the media sense feature
| being broken with multicast (even after disabling media sense)
| set the loopback attribute to true -->
| <UDP
| mcast_addr="${jboss.cache.SOMServicesProvisioningCache.addr:228.1.2.3}"
| mcast_port="${jboss.cache.SOMServicesProvisioningCache.port:48866}"
| ip_ttl="64" ip_mcast="true" mcast_send_buf_size="150000"
| mcast_recv_buf_size="80000" ucast_send_buf_size="150000"
| ucast_recv_buf_size="80000" loopback="false" />
| <PING timeout="2000" num_initial_members="3"
| up_thread="false" down_thread="false" />
| <MERGE2 min_interval="10000" max_interval="20000" />
| <!-- <FD shun="true" up_thread="true" down_thread="true" />-->
| <FD_SOCK />
| <VERIFY_SUSPECT timeout="1500" up_thread="false"
| down_thread="false" />
| <pbcast.NAKACK gc_lag="50"
| retransmit_timeout="600,1200,2400,4800" max_xmit_size="8192"
| up_thread="false" down_thread="false" />
| <UNICAST timeout="600,1200,2400" down_thread="false" />
| <pbcast.STABLE desired_avg_gossip="20000"
| up_thread="false" down_thread="false" />
| <FRAG frag_size="8192" down_thread="false"
| up_thread="false" />
| <pbcast.GMS join_timeout="5000"
| join_retry_timeout="2000" shun="true" print_local_addr="true" />
| <pbcast.STATE_TRANSFER up_thread="true"
| down_thread="true" />
| </config>
| </attribute>
|
|
| <!-- Whether or not to fetch state on joining a cluster -->
| <attribute name="FetchInMemoryState">true</attribute>
|
| <!-- The max amount of time (in milliseconds) we wait until the
| initial state (ie. the contents of the cache) are retrieved from
| existing members in a clustered environment -->
| <attribute name="InitialStateRetrievalTimeout">15000</attribute>
|
| <!-- Number of milliseconds to wait until all responses for a
| synchronous call have been received. -->
| <attribute name="SyncReplTimeout">15000</attribute>
|
| <!-- Max number of milliseconds to wait for a lock acquisition -->
| <attribute name="LockAcquisitionTimeout">10000</attribute>
|
| <!-- Indicate whether to use region based marshalling or not. Set this to true if you are running under a scoped
| class loader, e.g., inside an application server. Default is "false". -->
| <attribute name="UseRegionBasedMarshalling">true</attribute>
|
| <attribute name="CacheLoaderConfiguration">
| <config>
| <passivation>false</passivation>
| <preload>/</preload>
| <shared>true</shared>
| <cacheloader>
| <class>
| org.jboss.cache.loader.ClusteredCacheLoader
| </class>
| <properties>timeout=1000</properties>
| <async>true</async>
| <fetchPersistentState>false</fetchPersistentState>
| <ignoreModifications>false</ignoreModifications>
|
| </cacheloader>
| <!--
| som.cache.driver=${db.som.driver}
| som.cache.url=${db.som.url}
| som.cache.user=${db.som.user}
| som.cache.password=${db.som.password}
| -->
| <cacheloader>
| <class>
| org.jboss.cache.loader.JDBCCacheLoader
| </class>
| <properties>
| cache.jdbc.datasource=java:jdbc/somservices
| cache.jdbc.table.name=services_provisioning
| cache.jdbc.table.create=true
| cache.jdbc.table.drop=false
| cache.jdbc.table.primarykey=jbosscache_pk
| cache.jdbc.fqn.column=fqn
| cache.jdbc.fqn.type=varchar(255)
| cache.jdbc.node.column=node
| cache.jdbc.node.type=blob
| cache.jdbc.parent.column=parent
| </properties>
| <async>true</async>
| <fetchPersistentState>true</fetchPersistentState>
| <ignoreModifications>false</ignoreModifications>
| </cacheloader>
| </config>
| </attribute>
|
|
| </mbean>
|
|
| <!-- Uncomment to get a graphical view of the TreeCache MBean above -->
| <!-- <mbean code="org.jboss.cache.TreeCacheView" name="jboss.cache:service=TreeCacheView">-->
| <!-- <depends>jboss.cache:service=TreeCache</depends>-->
| <!-- <attribute name="CacheService">jboss.cache:service=TreeCache</attribute>-->
| <!-- </mbean>-->
|
|
| </server>
|
|
When we set a new node, it gets stored in database, but when we update one of the attributes of an already created node, it doesn`t get updated in database, even though there is no log indicating any problem, and JBC logs shows an update statement.
This seems to work right with MySql5, but not with Oracle9i.
Has anybody experienced an issue like this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112007#4112007
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112007
18 years, 4 months