[JBoss Seam] - request parameter gets ignored sometimes
by codelion
Starting out from seam-gen. Let's say we have three kinds of entities, Car, Boat and Plane. We only need Car to illustrate.
There is a page each like CarList.xhtml, Car.xhtml, CarEdit.xhtml and their CarList.page.xml, Car.page.xml, CarEdit.page.xml.
It all works fine with the generated code. Then my colleague introduces a different menu, and in that menu he doesn't use s:link with propagation="none". I'll explain what breaks and why it shouldn't break, it should work.
What breaks is this: Go to list of cars, go to view a car (select it), go on to edit the car, and then while on the car edit page, change your mind and go to somewhere else in the menu. Important: Do that with a link that isn't an s:link with propagation="none". Could happen, e.g. a help page, sidebar, top level menu, anything. You can't make the whole world (even in your company) use s:link. Then ... come back (e.g. through "the usual" link in the menu) to the list of cars, go to view another car, and voila, you're back at the car you selected first time, not the one you selected this time!
Just now to reproduce it I tried it a couple of times. First time I couldn't, probably not right sequence, but second or third time I got it again. When I demoed yesterday I got it all the time.
What seems to be broken is this: While in the list of cars the s:link to select (i.e. the one to view the car) does contain an f:param with a carId, and it does show up in the URL with the new carId, it seems "the model" (EntityHome?) keeps using the Car.id from last time. (Or CarHome's id. You know better. I'm just imitating seam-gen.
It is very clear and striking, up there in the Address field of the browser in the URL I see the correct carId for the newly chosen car, but in the display of contents below there is the wrong car id from before.
That shouldn't be that way, ever, should it? I mean that parameter is a clear indication of what should happen.
Now, in case that matters, there is an increase in cid (conversation id) from Car.xhtml to the CarEdit.xhtml through a propagation="begin", per seam-gen. While the use and non-use of propagation might be worth discussing anyway, the point is though that a request parameter shouldn't be ignored either way, right?
I'm not going to go into details about what I think about methods in Param.java, so as not to soil the team's thoughts with my possibly wrong ideas. I don't have a complete answer anyway, just some methods I tried following where they are used. Like getValueFromRequest in Param.java, versus getValueFromModel.
Running off CVS, building here.
PS: In Car.page.xml I have
<param name="carId" value="#{carHome.id}" />
Then as in CarHome I define
@Factory("car")
| public Car initCar() {
| return getInstance();
| }
I use in Car.xhtml fields like
<h:outputText id="description" value="#{car.description}" />
I don't use like seam-gen
<h:outputText id="description" value="#{carHome.instance.description}" />
Could that be related, or can someone make a statement that car and carHome.instance are identical objects, all the time, for the records?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4010487#4010487
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4010487
19Â years, 2Â months
[JBoss jBPM] - Re: hibernate AnnotationConfiguration rather than Configurat
by crussell42
IT WORKS!
After much head banging and incorrect assumptions I think I have it.
Please developers of jbpm can you look at this seriously as a means of persisting annotated pojos.
In HibernateHelper I added the following code
| import org.hibernate.cfg.AnnotationConfiguration;
| import org.hibernate.cfg.DefaultComponentSafeNamingStrategy;
| .
| .
| public static Configuration createConfiguration(String cfgXmlResource, String propertiesResource) {
| AnnotationConfiguration configuration = new AnnotationConfiguration();
| //NOT SURE WHY BUT configuration not picking up
| //hibernate.cfg.xml
| //<property name="hibernate.ejb.naming_strategy">
| //org.hibernate.cfg.DefaultComponentSafeNamingStrategy</property>
| log.debug("NAMING START STRATEGY ["+configuration.getNamingStrategy().getClass().getName()+"]");
| log.debug(configuration.setNamingStrategy(new DefaultComponentSafeNamingStrategy()));
| log.debug("NAMING AFTER STRATEGY ["+configuration.getNamingStrategy().getClass().getName()+"]");
|
With these changes you can now add mappings to the hibernate.cfg.xml
such as
| <mapping package="foo"/>
| <mapping class="foo.MyAnnotatedFooClass"/>
|
To pick up annotated classes....
Now I also had to put my classes in jbpm-jpdl.jar but I will figure out the class loader issues later.
Net effect: my annotated classes persist where I expect them to.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4010471#4010471
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4010471
19Â years, 2Â months
[JBoss Seam] - unit tests in a seam-genned app
by matt.drees
I seam-genned a blank app (called booking), then seam-genned a form (RegisterAction). I wanted to create a unit test (as in the Seam docs (http://docs.jboss.com/seam/1.1.5.GA/reference/en/html/testing.html#d0e130..., so I copy/pasted the code and tweaked some things:
| public class RegisterActionTest {
|
| @Test
| public void testRegisterAction()
| {
| }
|
| private EntityManagerFactory emf;
|
| public EntityManagerFactory getEntityManagerFactory()
| {
| return emf;
| }
|
| @Configuration(beforeTestClass=true)
| public void initialize()
| {
| emf = Persistence.createEntityManagerFactory("booking");
| }
|
| @Configuration(afterTestClass=true)
| public void destroy()
| {
| emf.close();
| }
| }
|
Running "ant test" gives me a javax.naming.NamingException: Local server is not initialized error in initialize().
If I extend SeamTest (which I think shouldn't be necessary for a unit test), I get a java.lang.NoClassDefFoundError: net/sf/ehcache/CacheException in initialize().
I think Seam-gen must not be including an EHCache jar, but I couldn't find where it is supposed to come from (or why the seam-genned integration test doesn't fail).
Also, should unit tests be required to extend SeamTest?
I'm running Seam from cvs.
Thanks for your help.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4010462#4010462
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4010462
19Â years, 2Â months
[Clustering/JBoss] - JBoss 4.0.5 Clustering Behavior
by davewebb
I have 2 physical servers running the same configuration
| JBoss 4.0.5
| J2SDK1.4.2_13
| OpenSuse 10.2
|
I have clustered an application on the 2 physical servers. Both servers startup fine, but when reviewing the logs I see the following:
| 2007-02-03 13:09:24,507 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] New cluster view for partition DefaultPartition: 8 ([192.168.1.73:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099] delta: 1)
| 2007-02-03 13:09:24,507 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] I am (192.168.1.74:1099) received membershipChanged event:
| 2007-02-03 13:09:24,507 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] Dead members: 0 ([])
| 2007-02-03 13:09:24,507 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] New Members : 0 ([])
| 2007-02-03 13:09:24,507 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] All Members : 9 ([192.168.1.73:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099])
| 2007-02-03 13:09:31,799 INFO [org.quartz.impl.jdbcjobstore.JobStoreTX] ClusterManager: detected 1 failed or restarted instances.
| 2007-02-03 13:09:31,800 INFO [org.quartz.impl.jdbcjobstore.JobStoreTX] ClusterManager: Scanning for instance "browning1170525665233"'s failed in-progress jobs.
| 2007-02-03 13:09:39,307 INFO [org.quartz.impl.jdbcjobstore.JobStoreTX] ClusterManager: detected 1 failed or restarted instances.
| 2007-02-03 13:09:39,307 INFO [org.quartz.impl.jdbcjobstore.JobStoreTX] ClusterManager: Scanning for instance "browning1170525665233"'s failed in-progress jobs.
| 2007-02-03 13:09:46,811 INFO [org.quartz.impl.jdbcjobstore.JobStoreTX] ClusterManager: detected 1 failed or restarted instances.
| 2007-02-03 13:09:46,811 INFO [org.quartz.impl.jdbcjobstore.JobStoreTX] ClusterManager: Scanning for instance "browning1170525665233"'s failed in-progress jobs.
| 2007-02-03 13:09:52,046 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32848 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|8], new vid: [browning:32852 (additional data: 17 bytes)|1])
| 2007-02-03 13:09:52,048 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32848 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|8], new vid: [browning:32852 (additional data: 17 bytes)|2])
| 2007-02-03 13:09:52,049 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32848 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|8], new vid: [browning:32852 (additional data: 17 bytes)|3])
| 2007-02-03 13:09:52,049 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32848 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|8], new vid: [browning:32852 (additional data: 17 bytes)|4])
| 2007-02-03 13:09:52,051 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32848 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|8], new vid: [browning:32852 (additional data: 17 bytes)|5])
| 2007-02-03 13:09:52,051 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32848 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|8], new vid: [browning:32852 (additional data: 17 bytes)|6])
| 2007-02-03 13:09:52,052 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32848 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|8], new vid: [browning:32852 (additional data: 17 bytes)|7])
| 2007-02-03 13:09:52,053 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32848 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|8], new vid: [browning:32852 (additional data: 17 bytes)|8])
|
Followed by
| 2007-02-03 13:12:33,063 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] New cluster view for partition DefaultPartition: 11 ([192.168.1.73:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099] delta: 1)
| 2007-02-03 13:12:33,063 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] I am (192.168.1.74:1099) received membershipChanged event:
| 2007-02-03 13:12:33,063 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] Dead members: 0 ([])
| 2007-02-03 13:12:33,063 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] New Members : 0 ([])
| 2007-02-03 13:12:33,063 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] All Members : 12 ([192.168.1.73:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099, 192.168.1.74:1099])
| 2007-02-03 13:12:37,008 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32863 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|11], new vid: [browning:32852 (additional data: 17 bytes)|1])
| 2007-02-03 13:12:37,009 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32863 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|11], new vid: [browning:32852 (additional data: 17 bytes)|2])
| 2007-02-03 13:12:37,011 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32863 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|11], new vid: [browning:32852 (additional data: 17 bytes)|3])
| 2007-02-03 13:12:37,011 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32863 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|11], new vid: [browning:32852 (additional data: 17 bytes)|4])
| 2007-02-03 13:12:37,012 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32863 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|11], new vid: [browning:32852 (additional data: 17 bytes)|5])
| 2007-02-03 13:12:37,012 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32863 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|11], new vid: [browning:32852 (additional data: 17 bytes)|6])
| 2007-02-03 13:12:37,014 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32863 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|11], new vid: [browning:32852 (additional data: 17 bytes)|7])
| 2007-02-03 13:12:37,014 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32863 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|11], new vid: [browning:32852 (additional data: 17 bytes)|8])
| 2007-02-03 13:12:37,017 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32863 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|11], new vid: [browning:32852 (additional data: 17 bytes)|9])
| 2007-02-03 13:12:37,018 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32863 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|11], new vid: [browning:32852 (additional data: 17 bytes)|10])
| 2007-02-03 13:12:37,018 ERROR [org.jgroups.protocols.pbcast.GMS] [mossberg:32863 (additional data: 17 bytes)] received view <= current view; discarding it (current vid: [browning:32852 (additional data: 17 bytes)|11], new vid: [browning:32852 (additional data: 17 bytes)|11])
|
While there are only 2 physical server and only 1 JVM running on each server, the servers keep adding members to the cluster with the same IP/Port combination.
Here is my cluster-service.xml
| <?xml version="1.0" encoding="UTF-8"?>
|
| <!-- ===================================================================== -->
| <!-- -->
| <!-- Sample Clustering Service Configuration -->
| <!-- -->
| <!-- ===================================================================== -->
|
| <server>
|
| <!-- ==================================================================== -->
| <!-- Cluster Partition: defines cluster -->
| <!-- ==================================================================== -->
|
| <mbean code="org.jboss.ha.framework.server.ClusterPartition"
| name="jboss:service=${jboss.partition.name:DefaultPartition}">
|
| <!-- Name of the partition being built -->
| <attribute name="PartitionName">${jboss.partition.name:DefaultPartition}</attribute>
|
| <!-- The address used to determine the node name -->
| <attribute name="NodeAddress">${jboss.bind.address}</attribute>
|
| <!-- Determine if deadlock detection is enabled -->
| <attribute name="DeadlockDetection">False</attribute>
|
| <!-- Max time (in ms) to wait for state transfer to complete. Increase for large states -->
| <attribute name="StateTransferTimeout">30000</attribute>
|
| <!-- The JGroups protocol configuration -->
| <attribute name="PartitionConfig">
| <!--
| The default UDP stack:
| - If you have a multihomed machine, set the UDP protocol's bind_addr attribute to the
| appropriate NIC IP address, e.g bind_addr="192.168.0.2".
| - On Windows machines, because of the media sense feature being broken with multicast
| (even after disabling media sense) set the UDP protocol's loopback attribute to true
| -->
| <Config>
| <UDP mcast_addr="${jboss.partition.udpGroup:228.1.69.1}" mcast_port="45566"
| ip_ttl="${jgroups.mcast.ip_ttl:8}" ip_mcast="true"
| mcast_recv_buf_size="2000000" mcast_send_buf_size="640000"
| ucast_recv_buf_size="2000000" ucast_send_buf_size="640000"
| loopback="false"/>
| <PING timeout="2000" num_initial_members="3"
| up_thread="true" down_thread="true"/>
| <MERGE2 min_interval="10000" max_interval="20000"/>
| <FD_SOCK down_thread="false" up_thread="false"/>
| <FD shun="true" up_thread="true" down_thread="true"
| timeout="10000" max_tries="5"/>
| <VERIFY_SUSPECT timeout="3000" num_msgs="3"
| up_thread="true" down_thread="true"/>
| <pbcast.NAKACK gc_lag="50" retransmit_timeout="300,600,1200,2400,4800"
| max_xmit_size="8192"
| up_thread="true" down_thread="true"/>
| <UNICAST timeout="300,600,1200,2400,4800" window_size="100" min_threshold="10"
| down_thread="true"/>
| <pbcast.STABLE desired_avg_gossip="20000" max_bytes="400000"
| up_thread="true" down_thread="true"/>
| <FRAG frag_size="8192"
| down_thread="true" up_thread="true"/>
| <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>
|
| <!-- Alternate TCP stack: customize it for your environment, change bind_addr and initial_hosts -->
| <!--
| <Config>
| <TCP bind_addr="thishost" start_port="7800" loopback="true"
| recv_buf_size="2000000" send_buf_size="640000"
| tcp_nodelay="true" up_thread="false" down_thread="false"/>
| <TCPPING initial_hosts="thishost[7800],otherhost[7800]" port_range="3" timeout="3500"
| num_initial_members="3" up_thread="false" down_thread="false"/>
| <MERGE2 min_interval="5000" max_interval="10000"
| up_thread="false" down_thread="false"/>
| <FD_SOCK down_thread="false" up_thread="false"/>
| <FD shun="true" up_thread="false" down_thread="false"
| timeout="10000" max_tries="5"/>
| <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false" />
| <pbcast.NAKACK up_thread="false" down_thread="false" gc_lag="100"
| retransmit_timeout="300,600,1200,2400,4800"/>
| <pbcast.STABLE desired_avg_gossip="20000" max_bytes="400000"
| down_thread="false" up_thread="false" />
| <pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true"
| print_local_addr="true" up_thread="false" down_thread="false"/>
| <FC max_credits="2000000" down_thread="false" up_thread="false"
| min_threshold="0.10"/>
| <FRAG2 frag_size="60000" down_thread="false" up_thread="true"/>
| <pbcast.STATE_TRANSFER up_thread="false" down_thread="false"/>
| </Config>
| -->
| </attribute>
| <depends>jboss:service=Naming</depends>
| </mbean>
|
| <!-- ==================================================================== -->
| <!-- HA Session State Service for SFSB -->
| <!-- ==================================================================== -->
|
| <mbean code="org.jboss.ha.hasessionstate.server.HASessionStateService"
| name="jboss:service=HASessionState">
| <depends>jboss:service=Naming</depends>
| <!-- We now inject the partition into the HAJNDI service instead
| of requiring that the partition name be passed -->
| <depends optional-attribute-name="ClusterPartition"
| proxy-type="attribute">jboss:service=${jboss.partition.name:DefaultPartition}</depends>
| <!-- JNDI name under which the service is bound -->
| <attribute name="JndiName">/HASessionState/Default</attribute>
| <!-- Max delay before cleaning unreclaimed state.
| Defaults to 30*60*1000 => 30 minutes -->
| <attribute name="BeanCleaningDelay">0</attribute>
| </mbean>
|
| <!-- ==================================================================== -->
| <!-- HA JNDI -->
| <!-- ==================================================================== -->
|
| <mbean code="org.jboss.ha.jndi.HANamingService"
| name="jboss:service=HAJNDI">
| <!-- We now inject the partition into the HAJNDI service instead
| of requiring that the partition name be passed -->
| <depends optional-attribute-name="ClusterPartition"
| proxy-type="attribute">jboss:service=${jboss.partition.name:DefaultPartition}</depends>
| <!-- Bind address of bootstrap and HA-JNDI RMI endpoints -->
| <attribute name="BindAddress">${jboss.bind.address}</attribute>
| <!-- Port on which the HA-JNDI stub is made available -->
| <attribute name="Port">1100</attribute>
| <!-- RmiPort to be used by the HA-JNDI service once bound. 0 => auto. -->
| <attribute name="RmiPort">1101</attribute>
| <!-- Accept backlog of the bootstrap socket -->
| <attribute name="Backlog">50</attribute>
| <!-- The thread pool service used to control the bootstrap and
| auto discovery lookups -->
| <depends optional-attribute-name="LookupPool"
| proxy-type="attribute">jboss.system:service=ThreadPool</depends>
|
| <!-- A flag to disable the auto discovery via multicast -->
| <attribute name="DiscoveryDisabled">false</attribute>
| <!-- Set the auto-discovery bootstrap multicast bind address. If not
| specified and a BindAddress is specified, the BindAddress will be used. -->
| <attribute name="AutoDiscoveryBindAddress">${jboss.bind.address}</attribute>
| <!-- Multicast Address and group port used for auto-discovery -->
| <attribute name="AutoDiscoveryAddress">${jboss.partition.udpGroup:230.0.0.4}</attribute>
| <attribute name="AutoDiscoveryGroup">1102</attribute>
| <!-- The TTL (time-to-live) for autodiscovery IP multicast packets -->
| <attribute name="AutoDiscoveryTTL">16</attribute>
| <!-- The load balancing policy for HA-JNDI -->
| <attribute name="LoadBalancePolicy">org.jboss.ha.framework.interfaces.RoundRobin</attribute>
|
| <!-- Client socket factory to be used for client-server
| RMI invocations during JNDI queries
| <attribute name="ClientSocketFactory">custom</attribute>
| -->
| <!-- Server socket factory to be used for client-server
| RMI invocations during JNDI queries
| <attribute name="ServerSocketFactory">custom</attribute>
| -->
| </mbean>
|
| <mbean code="org.jboss.invocation.jrmp.server.JRMPInvokerHA"
| name="jboss:service=invoker,type=jrmpha">
| <attribute name="ServerAddress">${jboss.bind.address}</attribute>
| <attribute name="RMIObjectPort">4447</attribute>
| <!--
| <attribute name="RMIClientSocketFactory">custom</attribute>
| <attribute name="RMIServerSocketFactory">custom</attribute>
| -->
| <depends>jboss:service=Naming</depends>
| </mbean>
|
| <!-- the JRMPInvokerHA creates a thread per request. This implementation uses a pool of threads -->
| <mbean code="org.jboss.invocation.pooled.server.PooledInvokerHA"
| name="jboss:service=invoker,type=pooledha">
| <attribute name="NumAcceptThreads">1</attribute>
| <attribute name="MaxPoolSize">300</attribute>
| <attribute name="ClientMaxPoolSize">300</attribute>
| <attribute name="SocketTimeout">60000</attribute>
| <attribute name="ServerBindAddress">${jboss.bind.address}</attribute>
| <attribute name="ServerBindPort">4446</attribute>
| <attribute name="ClientConnectAddress">${jboss.bind.address}</attribute>
| <attribute name="ClientConnectPort">0</attribute>
| <attribute name="EnableTcpNoDelay">false</attribute>
| <depends optional-attribute-name="TransactionManagerService">jboss:service=TransactionManager</depends>
| <depends>jboss:service=Naming</depends>
| </mbean>
|
| <!-- ==================================================================== -->
|
| <!-- ==================================================================== -->
| <!-- Distributed cache invalidation -->
| <!-- ==================================================================== -->
|
| <mbean code="org.jboss.cache.invalidation.bridges.JGCacheInvalidationBridge"
| name="jboss.cache:service=InvalidationBridge,type=JavaGroups">
| <!-- We now inject the partition into the HAJNDI service instead
| of requiring that the partition name be passed -->
| <depends optional-attribute-name="ClusterPartition"
| proxy-type="attribute">jboss:service=${jboss.partition.name:DefaultPartition}</depends>
| <depends>jboss.cache:service=InvalidationManager</depends>
| <attribute name="InvalidationManager">jboss.cache:service=InvalidationManager</attribute>
| <attribute name="BridgeName">DefaultJGBridge</attribute>
| </mbean>
|
| </server>
|
Any help is appreciated. Thank you!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4010458#4010458
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4010458
19Â years, 2Â months
[JBoss Seam] - Re: better editor for .xhtml in JBoss IDE - element wrapping
by codelion
Let's say I wrote
<div>
|
| <s:link view="/db/channelsList.xhtml"
| rendered="#{channelsQuery.previousExists}"
| value="#{messages.left}#{messages.left} First Page" id="firstPage">
| <f:param name="firstResult" value="0" />
| </s:link>
|
| <s:link view="/db/channelsList.xhtml" rendered="#{channelsQuery.previousExists}"
| value="#{messages.left} Previous Page" id="previousPage">
| <f:param name="firstResult" value="#{channelsQuery.previousFirstResult}" />
| </s:link>
|
| <s:link view="/db/channelsList.xhtml" rendered="#{channelsQuery.nextExists}"
| value="Next Page #{messages.right}" id="nextPage">
| <f:param name="firstResult" value="#{channelsQuery.nextFirstResult}" />
| </s:link>
|
| <s:link view="/db/channelsList.xhtml" rendered="#{channelsQuery.nextExists}"
| value="Last Page #{messages.right}#{messages.right}" id="lastPage">
| <f:param name="firstResult" value="#{channelsQuery.lastFirstResult}" />
| </s:link>
|
| </div>
With Eclipse | Window | Preferences | Web and XML | XML Files | XML Source I have settings: OFF Clear all blank lines. Same for HTML Files | HTML Source.
Then with Crtl-Shift-F and with Ctrl-I I get
<div><s:link view="/db/channelsList.xhtml"
| rendered="#{channelsQuery.previousExists}"
| value="#{messages.left}#{messages.left} First Page" id="firstPage">
| <f:param name="firstResult" value="0" />
| </s:link> <s:link view="/db/channelsList.xhtml" rendered="#{channelsQuery.previousExists}"
| value="#{messages.left} Previous Page" id="previousPage">
| <f:param name="firstResult" value="#{channelsQuery.previousFirstResult}" />
| </s:link> <s:link view="/db/channelsList.xhtml" rendered="#{channelsQuery.nextExists}"
| value="Next Page #{messages.right}" id="nextPage">
| <f:param name="firstResult" value="#{channelsQuery.nextFirstResult}" />
| </s:link> <s:link view="/db/channelsList.xhtml" rendered="#{channelsQuery.nextExists}"
| value="Last Page #{messages.right}#{messages.right}" id="lastPage">
| <f:param name="firstResult" value="#{channelsQuery.lastFirstResult}" />
| </s:link></div>
I just found out the HTML Files settings seem to apply, not the XML Files settings. How? Because when I change in HTML Files | HTML Source to ON Split multiple attributes each on a new line I get
<div><s:link
| view="/db/channelsList.xhtml"
| rendered="#{channelsQuery.previousExists}"
| value="#{messages.left}#{messages.left} First Page"
| id="firstPage">
| <f:param
| name="firstResult"
| value="0" />
| </s:link> <s:link
| view="/db/channelsList.xhtml"
| rendered="#{channelsQuery.previousExists}"
| value="#{messages.left} Previous Page"
| id="previousPage">
| <f:param
| name="firstResult"
| value="#{channelsQuery.previousFirstResult}" />
| </s:link> <s:link
| view="/db/channelsList.xhtml"
| rendered="#{channelsQuery.nextExists}"
| value="Next Page #{messages.right}"
| id="nextPage">
| <f:param
| name="firstResult"
| value="#{channelsQuery.nextFirstResult}" />
| </s:link> <s:link
| view="/db/channelsList.xhtml"
| rendered="#{channelsQuery.nextExists}"
| value="Last Page #{messages.right}#{messages.right}"
| id="lastPage">
| <f:param
| name="firstResult"
| value="#{channelsQuery.lastFirstResult}" />
| </s:link></div>
But it still ignores that I have OFF Clear all blank lines. My visual grouping with empty lines is gone.
And here is one that upset me, but I guess I can get used to it. From
<h:form id="searchForm" styleClass="formArea">
| <table class="formTable">
|
| <tr class="formRow">
| <td class="formFieldName">ID</td>
| <td class="formFieldValue">
| <h:inputText id="id" value="#{channelsQuery.channel.id}" />
| </td>
| </tr>
|
| <tr class="formRow">
| <td class="formFieldName">Title</td>
| <td class="formFieldValue">
| <h:inputText id="title" value="#{channelsQuery.channel.title}" />
| </td>
| </tr>
|
| </table>
| </h:form>
it makes
<h:form id="searchForm" styleClass="formArea">
| <table class="formTable">
|
| <tr class="formRow">
| <td class="formFieldName">ID</td>
| <td class="formFieldValue"><h:inputText id="id"
| value="#{channelsQuery.channel.id}" /></td>
| </tr>
|
| <tr class="formRow">
| <td class="formFieldName">Title</td>
| <td class="formFieldValue"><h:inputText id="title"
| value="#{channelsQuery.channel.title}" /></td>
| </tr>
|
| </table>
| </h:form>
Note how it pulled up the h:inputText. Now if I'd have wanted that without a space to the td I'd have put it there myself. But at least it lets my tr separated by lines.
Seems to have its own ideas there, with keeping spacing lines between tr but not between s:link, though it keeps whitespace in form of a single space between the s:link.
Decides for me I can't have whitespace between the td and its contents. Not ideal.
By now I can almost get used to it, after this discussion, but I still think it is less than good.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4010454#4010454
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4010454
19Â years, 2Â months