Mark McMillan

I have searched and struggled with this, but cannot successfully host a (simple example) GWT application in a google site page.

The only mechanism for this appears to be a google gadget on the page that contains the HTML and javascript. I have other (javascript-based) gadgets that work OK, but the GWT application never runs (just the HTML appears, but looks like the javascript does not execute). I uploaded the .js file and referenced it in the <script> tag something like:

<script type="text/javascript" language="javascript" src="https://sites.google.com/a/nc-mcmillans.com/sslive/slist.nocache.js"></script>

The HTML is rendered, but the GWT application never appears to run.

I have search google-sites help forums to no avail.

Has anyone hosted GWT apps on a google-sites page, and can you tell me how it works?

Thanks!
-Mark

Is there any technology that supports SSO for thick java clients connecting to a J2EE application server via RMI/IIOP? Our thick client makes EJB calls to the server and uses JMS to listen for events on topics. The server (WebSphere) authenticates using LDAP.

A customer wants to have our thick client pick up the local (Windows or unix) user credentials and use them to logon to the server without prompting the user for ID or password. Kerberos has been mentioned as a possible enabler for something like this.

Is such a scenario feasible? Is there existing technology and support for this?

I may not be completely understanding your requirements, but it seems you have a burst of activity (lots of DB records) and you need to process them in parallel, but you have only a single timer bean running.

What if the timer bean only scans the incoming records, and for each one posts a message which contains the record ID (primary key or whatever is necessary to identify a particular record). An MDB receives the messages and processes them one at a time by reading the incoming DB record and doing whatever (2 second) processing is needed.

Now, configure your server to support whatever degree of parallelism you want for the MDB. For example, in WebSphere you configure the "Maximum concurrent endpoints" to the number of (concurrent) instances of the MDB the server will create to handle messages from that particular JMS topic. If you set this value to 10, then the server will create up to 10 instances of the MDB, each running in parallel pulling messages off the same queue.

It probably depends on the implementation of the server. Your code should not make any assumptions.

In WebSphere if the WAR and EJBs are deployed in the same server, then the JSP thread will call directly into the EJB container and it will run the EJB code there. However, if the WAR is deployed in a separate server (e.g. in the web tier) then of course the JSP's thread cannot be used (it does not exist in the EJB server). In that case the EJB is run with a container thread and the JSP thread is blocked (waiting) in the RMI call.

Other vendors (e.g. WebLogic) may behave differently when both containers are in the same JVM. When they are separate JVMs, the same thread cannot be used no matter the vendor.

Our EJB application has a number of configuration options that the application installer/administrator and setup. Currently this is done by editing a properties file (on the server file system, external to the EAR). The installer sets a JVM property ("-Dourapp.configfile=xxxx") to the location of the file. We read that properties file and it control various options in our application.

This of course violates the J2EE specs (our EJBs should not be doing file I/O on the server). This also does not work in a clustered environment where the nodes in the cluster may not have access to a shared file system, and the installer should not have to copy the properties file to every node.

So the question is, what is the best J2EE-compliant mechanism for application configuration data? If the configuration data is changed while the application is running, is there a (J2EE) way for the application to be notified?

Thanks for any ideas...
-Mark