Discussions

News: WebCream 5.0 released - Swing/HTML bridge

  1. WebCream 5.0 is the latest release of the HTML-Swing bridge that provides automatic conversion of Java GUI applications into the interactive HTML websites.

    What's new in 5.0

    - JDK 1.5 support
    - Powerful RequestFilter and AgentRenderFilter interfaces have been added
    - Improved rendering of JTables with custom cell editors and renderers
    - All messages that appear in HTML are moved to the application properties file
    - Full JavaDoc API documentation is available for WebCream
    - Resizable splitter supported for Netscape 7.x

    More information at http://www.creamtec.com/webcream/
  2. Sounds interesting, I will download one to test it.
  3. Demo on website is pretty impressive. Be interesting to sample it on a more intense existing Swing project.

    BTW: SWT compatibility coming?
  4. George,

    There are no immediate plans to support SWT. Most of the customers use Swing and so far we haven't been getting a lot of requests about SWT support. It may have to do with the fact that our product generates most of the interest with the companies that have been investing into GUI development for a while, which is why Swing/AWT is the dominant platform.
  5. Has anyone tried Webcream and Webonswing that could post a comparison between the two frameworks?
  6. This looks like a neat concept. I played with it quickly to see if our RMI client order entry application would run under WebCream.

    The login screen came up which was very exciting. When I login, the application tries to connect to the weblogic RMI server. I kept getting a ClassNotFoundException on a WebLogic class. It was neat that our application's error dialog was displayed in HTML; but it was not so neat that I can't get any further.

    I'll try some more another time since it would be such a nice alternative to our Swing-based client.

    javax.naming.NoInitialContextException: Cannot instantiate class: weblogic.jndi.WLInitialContextFactory [Root exception is java.lang.ClassNotFoundException: weblogic.jndi.WLInitialContextFactory]
    at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:652)
    at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)
    at javax.naming.InitialContext.init(InitialContext.java:219)
    at javax.naming.InitialContext.<init>(InitialContext.java:195)
    at com.mbasys.mars.javaApp.rmi.MarsRmiHelper.getInitialContext([DashoPro-V2.1-110100])
    at com.mbasys.mars.javaApp.userInterface.RmiLogonManager.initInterface([DashoPro-V2.1-110100])
    at com.mbasys.mars.javaApp.userInterface.RmiLogonManager.logon([DashoPro-V2.1-110100])
    at com.mbasys.mars.oe.OEApplet.login([DashoPro-V2.1-110100])
    at com.mbasys.mars.oe.OEApplet.init([DashoPro-V2.1-110100])
    at com.mbasys.mars.oe.OEApplet.main([DashoPro-V2.1-110100])
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at creamtec.webcream.core.ClientAgent.a(ClientAgent.java:725)
    at creamtec.webcream.core.ClientAgent.doRun(ClientAgent.java:691)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at creamtec.webcream.core.l.b(l.java:150)
    at creamtec.webcream.core.l.run(l.java:46)
    Caused by: java.lang.ClassNotFoundException: weblogic.jndi.WLInitialContextFactory
    at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:219)
    at com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:42)
    at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:649)
    ... 21 more
  7. John,

    Make sure that you have followed the installation and setup instructions. If your client uses WebLogic classes, you will have to make sure that it can load them from weblogic.jar. You can copy that file to WebCream/wcapps/lib or add it to system CLASSPATH.

    CLASSPATH issues should be easy to resolve, check the documentation and contact our tech support if you need help.
    This looks like a neat concept. I played with it quickly to see if our RMI client order entry application would run under WebCream.The login screen came up which was very exciting. When I login, the application tries to connect to the weblogic RMI server. I kept getting a ClassNotFoundException on a WebLogic class. It was neat that our application's error dialog was displayed in HTML; but it was not so neat that I can't get any further.I'll try some more another time since it would be such a nice alternative to our Swing-based client. javax.naming.NoInitialContextException: Cannot instantiate class: weblogic.jndi.WLInitialContextFactory [Root exception is java.lang.ClassNotFoundException: weblogic.jndi.WLInitialContextFactory] at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:652) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243) at javax.naming.InitialContext.init(InitialContext.java:219) at javax.naming.InitialContext.<init>(InitialContext.java:195) at com.mbasys.mars.javaApp.rmi.MarsRmiHelper.getInitialContext([DashoPro-V2.1-110100]) at com.mbasys.mars.javaApp.userInterface.RmiLogonManager.initInterface([DashoPro-V2.1-110100]) at com.mbasys.mars.javaApp.userInterface.RmiLogonManager.logon([DashoPro-V2.1-110100]) at com.mbasys.mars.oe.OEApplet.login([DashoPro-V2.1-110100]) at com.mbasys.mars.oe.OEApplet.init([DashoPro-V2.1-110100]) at com.mbasys.mars.oe.OEApplet.main([DashoPro-V2.1-110100]) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at creamtec.webcream.core.ClientAgent.a(ClientAgent.java:725) at creamtec.webcream.core.ClientAgent.doRun(ClientAgent.java:691) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at creamtec.webcream.core.l.b(l.java:150) at creamtec.webcream.core.l.run(l.java:46)Caused by: java.lang.ClassNotFoundException: weblogic.jndi.WLInitialContextFactory at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:219) at com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:42) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:649) ... 21 more
  8. Making progress[ Go to top ]

    Thanks for the advice on my classpath issue.

    I have now gotten past that initial NoClassDefFound error on the weblogic class. My new issue is apparently a conflict between the old log4j version that we use vs whatever is being used internally by WebCream (or actually tomcat maybe?).

    java.lang.NoClassDefFoundError: org/apache/log4j/Priority
    at com.mbasys.mars.oe.OEApplet.<clinit>([DashoPro-V2.1-110100])
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at creamtec.webcream.core.ClientAgent.a(ClientAgent.java:725)
    at creamtec.webcream.core.ClientAgent.doRun(ClientAgent.java:691)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at creamtec.webcream.core.l.b(l.java:150)
    at creamtec.webcream.core.l.run(l.java:46)

    I realize that this message thread is not your support forum. I assume I should take my questions there?

    Your product looks fantastic and I'm sure these issues are due to my environment not being configured properly.
  9. Making progress[ Go to top ]

    John,

    Glad to see you are moving along. WebCream doesn't use Log4J, but Tomcat that is shipped with WebCream does. If your app needs Log4J and the one in Tomcat is conflicting with the one you are using, you have several options.

    1. You can use agent.classPath setting in the application configuration file to explicitly pick the JARs you want on the CLASSPATH for your application.

    2. You can run your application in stand alone mode in which case it will not execute inside Tomcat JVM. That way your CLASSPATH is independent of Tomcat CLASSPATH.

    Read documentation for more information on these options.

    If that doesn't solve the problem, contact our technical support and make sure to send the output of environment.jsp.

    As for the posting to this forum, as long as you feel the question might be of interest to other readers it should be fine. If it's a problem you are experiencing in your application and you need support, better contact us directly.
  10. WebCream vs WebOnSwing[ Go to top ]

    Even though I am closely associated with WebCream development I will try to present an unbiased comparision of the two frameworks. My exposure to WebOnSwing is limited to reading the documentation, playing with their demos and checking out the source code.

    Both products have similar architecture. They substitute the graphics environment and AWT toolkit to emulate the execution of Swing application at runtime. The both convert Swing windows to HTML pages. I have listed the pros and cons for each product below:

    WebOnSwing Pros:
    - Free, open source, distributed under LGPL
    - HTML templates for simple customization of rendering

    WebOnSwing Cons:
    - Lack of support for many Swing controls (JSplitPane, JScrollPane, others)
    - Requirement (?) to provide HTML templates for Swing windows. If it is optional, then it's a good thing, but if the developer has to provide a template for each window then it can be time consuming.
    - Close integration with the GUI app. Again, it may be optinal, but I am not sure that you can run the GUI app as a true Swing app without WebOnSwing.
    - Products needs to be more mature to be feasible for production environments. It currently ships as a Beta version.

    WebCream Pros:
    - Mature product ready for production. Has a customer base which means that most of the bugs and features are taken care of.
    - Complete implementation of Swing controls
    - Snapshot renderer that can capture any control as an image to support custom controls
    - Various customazations via custom renderers, updaters and action emulators
    - Built in load balancing to distribute the emulation of virtual clients
    - Complete separation of emulated web appliction from GUI Swing application. At any point in time the Swing app can run as is.
    - No requirement to change the Swing app in order to make it run as a website
    - Professional technical support for production environments

    WebCream Cons:
    - License fees. The product is distributed under a commercial license. However, the pricing starts at around 1K and the source code can be purchased as well.
    - Source code is not available for free evaluation

    The bottom line to me is that WebCream is a clear winner for a production environment. However, if the license fees are a show stopper, keep an eye on WebOnSwing because it has good potential to mature into a serious competitor to WebCream.
  11. WebCream vs WebOnSwing[ Go to top ]

    I'm the creator of WebOnSwing Framework, and I'd like to explain some differences that I see between WebOnSwing and WebCream:

    * One of the biggest difference is the architecture, WebOnSwing can wrap not only Swing applications, if you implement certain interfaces for hierarchy wrapping, component wrapping, window management, etc, you may wrap any other component framework such as SWT, JSF, Tapestry, Echo, .NET, etc. There are examples of SWT wrapping and custom components implementation.
    * Other big difference is that WebOnSwing main purpose is suply a multi environment application framework that reuse Swing architecture and all its related tools and extensions (visual editors of almost every IDE, Thrid Party components and LayoutManagers, etc). The idea is that it totally separated the common UI behavior and the HTML specific "things". So you develope an application in an unique way and with some agregations you can deliver this application to a any other enviroment (such as a web one).
    * It is true that WebOnSwing also could be used for migrating Swing applications to web, but this migration is not totally transparent because we didn't replace awt or swing classes to override methods like 'show' or 'hide', instead of this we choose the use static methods provided by the framework. And these methods can be called also when WebOnSwing framework is disabled, keeping the same behavior of show and hide original methods because when you are working in desktop environment this static method just delegates the call to Component setVisible method (show and hide).
    * HTML templates are not required for Swing desktop applications. In almost all windows you will probably use the 'PropagateTemplateLayoutByName' that will no have any effect in a desktop environment and it is set only in top parent component. And in case the user needs to apply a TemplateLayout directly, he may provide a 'KeyPositionSwingTemplate' that has a collection of Containers inside, and place each component in the corresponding Container coordinates.
    * HtmlTemplates dont have any special thing inside, they dont have logic or special stags, it comes directly from the graphic designer. So the use of skins is really easy (look at JMenu or JTree skins!).
    * Another difference is that WebOnSwing provides a persistence engine (similar to .NET viewstate) that allows you to work with stateless pages. Storing persisted data in page can reconstruct a previus window state and continue the cycle. So using this feature the server dont have to store window instances in session, or any other data, reaching high scalability levels.
    * A powerful and complete validation framework (similir to .NET)
    * Component refreshing (or partial updates), that updates only the parts of the page that change from the last resquest.