
By Celine

Which one better?
All About Jimmy6, Java, Gwt, Spring, Hibernate, Google...

Social networking<config>
<TCP start_port="7810" loopback="true" bind_addr="${bind.address}"
tcp_nodelay="true"
recv_buf_size="20000000"
send_buf_size="640000"
discard_incompatible_packets="true"
enable_bundling="false"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="false"
down_thread="false" up_thread="false"
use_send_queues="false"
sock_conn_timeout="300"
skip_suspected_members="true"/>
<TCPPING initial_hosts="192.168.0.7[7810]" port_range="3"
timeout="3000"
down_thread="false" up_thread="false"
num_initial_members="3"/>
<MERGE2 max_interval="100000"
down_thread="false" up_thread="false" min_interval="20000"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<FD timeout="10000" max_tries="5" down_thread="false" up_thread="false" shun="true"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="300,600,1200,2400,4800"
down_thread="false" up_thread="false"
discard_delivered_msgs="true"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
down_thread="false" up_thread="false"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
down_thread="false" up_thread="false"
join_retry_timeout="2000" shun="true"
view_bundling="true"/>
<FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<FRAG2 frag_size="60000" down_thread="false" up_thread="false"/>
<pbcast.STATE_TRANSFER down_thread="false" up_thread="false" use_flush="false"/>
</config>
<Config>
<TCP start_port="7800" loopback="true" bind_addr="${bind.address}"
tcp_nodelay="true"
recv_buf_size="20000000"
send_buf_size="640000"
discard_incompatible_packets="true"
enable_bundling="false"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="false"
down_thread="false" up_thread="false"
use_send_queues="false"
sock_conn_timeout="300"
skip_suspected_members="true"/>
<TCPPING initial_hosts="192.168.0.7[7800]" port_range="3"
timeout="3000"
down_thread="false" up_thread="false"
num_initial_members="3"/>
<MERGE2 max_interval="100000"
down_thread="false" up_thread="false" min_interval="20000"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<FD timeout="10000" max_tries="5" down_thread="false" up_thread="false" shun="true"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="300,600,1200,2400,4800"
down_thread="false" up_thread="false"
discard_delivered_msgs="true"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
down_thread="false" up_thread="false"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
down_thread="false" up_thread="false"
join_retry_timeout="2000" shun="true"
view_bundling="true"/>
<pbcast.STATE_TRANSFER down_thread="false" up_thread="false" use_flush="false"/>
</Config>
</attribute>
<depends>jboss:service=Naming</depends>
</mbean>
<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">${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">${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>
Compile output size and runtime performance are two separate issues. A
third party widget written in GWT Java, regardless of how small it compiles down
to, doesn't magically make it run fast. Nor does it make it magically render
perfectly on all browsers. As an example a TableGrid written in GWT Java could
still perform really poorly, and not display consistently on all browsers.
There are obviously several aspects to GWT that helps avoid leaks and such
but this does not mean that any third party code written in GWT is
100% leak free. The GWT 1.6 event API is really neat and SmartGWT users
it. Well written code is what will perform well and display consistently
across various browser.
On the issue of performance, there are numerous posts
made by paying GXT users that the performance of GWT-Ext is still better than
GXT. You can search their forums. This is not to suggest that performance
improvements cannot be made in SmartGWT. If you can give specifics, it would
certainly help in resolving them. But without specifics like whether it was the
initial load time, performance of specific widgets etc it will be difficult to
act on. Feel free to post on the SmartGWT forums or create an issue on the
smartgwt google code project.
On the issue of compile output size : The
SmartClient library is extremely stable and developed over the past 8 years.
If you peruse their forums, you will find that pretty much all questions
are met with an answer explaining how the user can accomplish what they're
trying to do. Their library is virtually bug free. I realize this is a strong
statement, but its true. Only some 4-5 issues were patched
post-release. Compare this to the bugs forum of any of
your favorite libraries. SmartGWT will inherit these attributes
once its past the few initial minor releases and issues are flushed out during
this period. Due to the high level of stability of SmartClient, it can be
viewed as the kernel of your web app which should be configured to be
gzipped with an "Expires Never" header for a given version. This means that the
browser will cache the "kernel" (SmartClient JS files) and the only code that
gets downloaded is your application code, and not any code related to the widget
/ framework. Future releases of SmartGWT will provide a GWT linker that only
pulls in the required files so this should cut down the total size of the
application.
The SmartGWT showcase has some 250 samples which is 6 times more
than the GXT showcase so its not quite apples to apples when it comes to initial
load time.
Finally please read my blog entry http://www.jroller.com/sjivan/entry/smartgwt_1_0_released if
you haven't already done so. I go over the SmartGWT fundamentals, the concept of
a DataSource and how it will lead to a cleaner architecture and can cut
application code significantly. I mention how a master detail page can be
written in as little as 10 lines using a reusable DataSource definition that
describes an entity / model class. Plus the reduced number of lines of code on
the server as well.This is the first release of SmartGWT and while it is quite
stable and has been tested and used by early adopters for the past four weeks,
users can expect any rough edges / bugs / performance issues / better skins etc
to be ironed out over the course of the next few minor releases.As mentioned
earlier, if users have found a library that meets their needs, thats great and
there's no need to look further. And for the others, feel free to evaluate
SmartGWT to see if it helps meet your requirements. If you feel that there are
things that can be improved please post on the SmartGWT forum or create an issue
on the google code project page.