Resizing of the Root

Everything that extends Region or Control and is set as the root will automatically fit to the Scene. Anything that extends Group will not.

If you do not want the application to resize with the scene, add a Group as the root.

 
Resizing of Child Nodes

The size of a resizable node (Region, Control, WebView) will depend on two things:
1) It's own min/pref/max size preferences
2) The sizing policy of its parent


Following is a brief description of how the various nodes will be resized if the following are the Parent containers:


FlowPane: FlowPane will always resize nodes to their preferred sizes. This means controls added to a flowpane won’t resize if you resize the application window. FlowPane should contain only those controls for which resizing is not required.


StackPane: StackPane will attempt to resize its children to fill its area (up to the child's max size limits).This means that a node’s default MAX size has everything to do with how its resize.


All Layout panes and most of the controls have an unbounded max size, which means a StackPane will stretch them out. The exceptions:
- Label, Buttons, Hyperlink, Slider, ProgressBar returns pref size for max (so they don't stretch by default)
- MenuBar, TextBox return pref for max height (width is unbounded)

If you don't want a GridPane to be stretched beyond its preferred size, just clamp it:
gridpane.setMaxSize(Region.USE_PREF_SIZE, Region.USE_PREF_SIZE);

if you want a Button's width to be flexible:
button.setMaxWidth(Double.MAX_VALUE);


GridPane:  

The sizing of rows and columns in a GridPane will depend on the percentage width set for the CoulmnConstraints and percentage height set for the RowContraints. The code below sets the percentage with for column 1 and 2 and percentage height of rows 1 to 4


  ColumnConstraints column1 = new ColumnConstraints();

          column1.setPercentWidth(50);

         

          ColumnConstraints column2 = new ColumnConstraints();

          column2.setPercentWidth(50);

     

  configurationPane.getColumnConstraints().addAll(column1, column2);

          

          RowConstraints rowConstraints1=new RowConstraints();

          rowConstraints1.setPercentHeight(30);

          

          RowConstraints rowConstraints2=new RowConstraints();

          rowConstraints2.setPercentHeight(30);

         

          RowConstraints rowConstraints3=new RowConstraints();

          rowConstraints3.setPercentHeight(30);

         

          RowConstraints rowConstraints4=new RowConstraints();

          rowConstraints4.setPercentHeight(10);

          configurationPane.getRowConstraints().

          addAll(rowConstraints1,rowConstraints2,rowConstraints3,rowConstraints4);


Once the rows and columns of Grid are resized the sizing of the nodes within each of them would behave based on the resizing policy of the controls as discussed under stack pane.


VBox:

 
The setVgrow method sets the vertical grow priority for the child when contained by an VBox. If set, the VBox will use the priority to allocate additional space if the VBox is resized larger than its preferred height. If multiple VBox children have the same vertical grow priority, then the extra space will be split evening between them. If no vertical grow priority is set on a child, the VBox will never allocate it additional vertical space if available. Setting the value to null will remove the constraint.


HBox:

The setHgrow method sets the horizontal grow priority for the child when contained by an HBox. If set, the HBox will use the priority to allocate additional space if the HBox is resized larger than its preferred width. If multiple HBox children have the same horizontal grow priority, then the extra space will be split evening between them. If no horizontal grow priority is set on a child, the HBox will never allocate it additional horizontal space if available. Setting the value to null will remove the constraint


BorderPane:

 
Border Pane again uses the resizing policy of the nodes as discussed under stack pane to resize the nodes.


Left Node: If the node placed on the left edge of the border pane is resizable, it will be resized to its preferred width and the height will span the height of the border pane between the top and bottom nodes. If the node cannot be resized to fill the left space (it's not resizable or its max size prevents it) then it will be aligned top-left within the space unless the child's alignment constraint has been set.


Right Node: If the node placed on the right edge of this border pane is resizable, it will be resized to its preferred width and its height will span the height of the border pane between the top and bottom nodes. If the node cannot be resized to fill the right space (it's not resizable or its max size prevents it) then it will be aligned top-right within the space unless the child's alignment constraint has been set.

 

Top Node: If the node placed on the top edge of this border pane is resizable, it will be resized to its preferred height and its width will span the width of the border pane. If the node cannot be resized to fill the top space (it's not resizable or its max size prevents it) then it will be aligned top-left within the space unless the child's alignment constraint has been set.


Bottom Node: If the node placed on the bottom edge of the border pane is resizable, it will be resized to its preferred height and its width will span the width of the border pane. If the node cannot be resized to fill the bottom space (it's not resizable or its max size prevents it) then it will be aligned bottom-left within the space unless the child's alignment constraint has been set.


References:

JavaFX JavaDocs : http://download.oracle.com/javafx/2.0/api/index.html

This Blog is in continuation of my first blog on OSGi.

In the first part we saw what OSGi is and what benefits it offers. In this section I would like to share my experience in evaluating OSGi for developing a Web based application, the challenges I faced, Spring DM server and DM Server development tools for developing OSGi applications. Next I would also share some of my experience in using Spring DM Server for an actual development project

After doing my initial research of the OSGi framework I decided to start my journey on developing a sample Web based application on OSGi. 

I soon realized my research is not complete and I still had to explore on how to integrate a Web based application within an OSGi container.  I also had to explore on the development tools to be used.

Challenges in developing an OSGi based web application

I faced an interesting challenge here. OSGi applications need to work within an OSGi container whereas Web applications run within a Web Container.

To resolve this issue one can either embed the Web Container bundle (Tomcat bundle or Jetty bundle) within OSGi container or deploy the OSGi platform as a war within the Web Container. I particularly didn’t find these approaches amusing but with no other option left chose the first option.  

Oops faced one more challenge here. Tomcat bundle was not readily available. I went through various forums and site where they explained how to build a tomcat bundle. Not to delay my progress I decided to use Jetty bundle which was readily available. It did take time for me to do the initial setup but finally I was set to start my development.

I was using PAX-Construct for handling the OSGi container and for deploying the various OSGi bundles. I went through the various steps that are required to develop a bundle and deploy it using PAX- Construct .I tried a few examples and found the steps to be too exhaustive and time consuming. Searching the open source library bundles manually, installing them and updating the Manifest file was becoming a nightmare. Instead of focusing on business logic my major time was getting spent in OSGi related activities.

My excitement about OSGi was coming down and I was thinking may be OSGi development tools are not matured enough and OSGi is best suited only for desktop based application. I wanted to have a simple deployment container for OSGi Web applications and easy to use development tools.

 I wanted to do more research in this area before coming to a final conclusion and so I continued my research on OSGi in the web mode.

After going through several sites and forums I found the OSGi Enterprise Experts Group is working on the RFC66 standard for OSGi web container. I also came across several claims about Spring DM server being the best reference implementation of the standard. I didn’t come across any other implementation of the standard so couldn’t do much of the comparison here and finally decided to do more analysis of the DM Server.

Just after spending a couple of hours on the Spring DM server I found SpringSource has resolved both of my previous concerns.  Spring DM Server served as a ready platform for deploying OSGi based web applications and Spring Source DM Server Tools provided very good Eclipse development environment for Spring DM server based applications.

Let’s have a look at what Spring DM Server and its development tools provides us

Spring DM Server

1. Spring DM Server is a lightweight, modular, OSGi-based runtime that provides a complete packaged solution for developing, deploying, and managing enterprise applications.
2. The SpringSource dm Server is built on top of the following core technologies:
3. Spring Framework
4. Tomcat as the web container.
5. OSGi R4.1.
6. Equinox as the OSGi implementation.
7. Spring Dynamic Modules for OSGi for working with OSGi in a Spring application.
8. SpringSource Tool Suite for developing applications.
9. Spring Application Management Suite for monitoring the SpringSource dm Server and the applications that have been deployed to it.

Key Capabilities Include:

Admin Console: deploy and manage artifacts, examine diagnostic dumps, and examine bundle wiring, either in the live system or from a resolution failure

Equinox console extension – manage DM Server and deployed artifacts

Plans - define the artifacts that comprise an application, optionally making the application atomic to tie the artifact lifecycles together, and scoped to isolate the application from other applications

Provisioning - automatically supply the dependencies of an application including bundles, plans, plan archives (PARs), and configurations, from both local and remote repositories

Web container - supports vanilla WAR files, with all their dependencies in WEB-INF/lib, and Web Application Bundles, that import their dependencies via OSGi manifest metadata, via the embedded Tomcat-based reference implementation of the OSGi Web Container specification, configured using the standard Tomcat server.xml

User Region - isolates the kernel from user-installed applications and enables admins to focus on application artifacts and their dependencies without seeing those of the kernel as well

Spring 3 –Spring DM Server packages Spring 3.0 final, but can easily be configured to use a different version of Spring.

Hot deployment - deploy artifacts to Virgo by copying them into the pickup directory, either in archive or exploded form, as an alternative to deploying via the admin console

Logging - via embedded LogBack, configured in config/serviceability.xml, with a rich set of appenders available out of the box

Spring Source Tool Suite

SpringSource provides a set of plug-ins for the Eclipse IDE that streamlines the development lifecycle of OSGi bundles and PAR applications. The SpringSource dm Server Tools build on top of the Eclipse Web Tools Project (WTP) and Spring IDE, the open-source Spring development tool set.

 The SpringSource dm Server Tools support the creation of new OSGi bundle and PAR projects within Eclipse, and the conversion of existing projects into OSGi bundle projects. Projects can then be deployed and debugged on a running dm Server from within Eclipse.

Experience of using Spring DM Server in Live Project

 I developed a sample Web application based on Spring DM server and its development tools. Once all stake holders were convinced we decided to use it for our next development project.  

At the time of writing this blog its beings six months we have been using Spring DM server in actual development. Following are some of my experiences in this period:

1. Technical Documentation: Spring Source has come up with a detailed documentation for setting up the server and developing/migrating a web based application using Spring DM server.We were able to resolve most of our setup and development issues by referring to the Spring Source provided documents. We also got answers to most of our queries from Spring DM server forums but still there were some situations where in we had to struggle for our problems.But overall we would rate the documentation and the forum support to be fairly good.
2. Spring Source Repository: Spring Source has come up with an online repository where you can find OSGi bundles and libraries for all major Java open source libraries. For our development project we were able to find 95% of our open source bundles readily available here which saved our search time to a great extent.
3. Hibernate integration: It was very easy to integrate Hibernate in our application. The OSGified Hibernate Library was readily available with the Spring Source repository and we had to follow the standard Spring – Hibernate integration process.
4.  Axis 2.0 integration: We faced lot of issues here. The Axis 2.0 bundles were not readily available. There were some sites which OSGified the bundles but deploying these was causing lot of version conflicts with other bundles.Since the Web Service code was part of a single web bundle and was not required to be decomposed into smaller bundles we decided to use the normal Axis 2.0 libraries. We deployed the standard Axis2.0 libraries in the lib folder of our web bundle and were able to integrate Axis without further issues.
5.  Tiles Integration: Again we faced bundle conflict issues here. There were version conflicting issues with the Tiles library and Spring 3.0 Library. To resolve the issue we had to provide reference to a couple of core Spring 2.5 library
6. Spring DM Server integration within Eclipse: The development tools provide seamless integrations of Spring DM server with Eclipse. We were able to Start, Stop the server, Deploy and Redeploy PAR files from within Eclipse easily. Debugging the application code was also very easy and we had to follow the standard debug process here.
7. Deploying Open source bundles from the development environment:  This is one of the best features provided by the development tools. The development tools provide easy integration with various online repositories from where the OSGi bundles/libraries can be downloaded and integrated for an application. Using this feature we were able to search and deploy open source OSGi bundles and libraries easily for our application.
8. Manifest file manipulation from Development environment:   The development tools provide an excellent User Interface for importing packages from other bundles and for exporting packages of a bundle. The actual Manifest file is automatically generated based on the selections made from the User Interface. This saves lots of Manifest file management hassles.
9. Using Maven for continuous Integration :  We are still doing research in this area. Our intial research suggests using Maven for build process results in losing lots of benefits offered by the development tools. At the moment we are using only the development tool for building and deploying the PAR project but we would definitely want integration with Maven to streamline the integration and build process.

To conclude OSGi provides a great platform for building modular Java applications in a true sense. OSGi is proven technology adapted by many open source and proprietary  Java Enterprise servers and applications .Spring DM server looks promising as an OSGi web container and the DM server tools greatly simplify the OSGi development tasks. With the standardization of the OSGi web container specifications and Spring Source being actively involved in its implementation we would expect adaption of OSGi in many future Java Web application developments.

Finally I would support the quote posted on Spring Source site by Jan Hendrik  Kuperus ‘ Spring DM Server is the future of Java EE’.

PS: At e-Zest, we work on emerging technologies & solutions based on OSGi component framework & Enterprise OSGi specification. Please feel free to email me your queries regarding OSGi on our corporate email id: info@e-zest.net

OSGi:

Eclipse IDE is one of the extensively used Java development tool and I have been using it from the start of my Java programming career. One of the key features of Eclipse which impresses me a lot is its plugin architecture. To add support for a new feature we just download the relevant plugins, copy them to the plugins folder and after a restart all the required menus are in place and all the new features are available at our disposal.

I always wanted to develop an application on a similar architecture but due to other project priorities couldn’t research a lot on this. After 7 years of my S/W career I was finally struck with an opportunity to develop an application based on the OSGi Framework. As I started my research on OSGi framework I realized this is what I had been waiting for a long time.

What is OSGi?

From my initial discussions you must have got a clue that OSGi development is somewhere related to plugin development. Correct OSGi framework allows us to build highly modular Java applications composed of small components.

To define it more correctly the OSGi Framework provides the standardized specifications that allow applications to be constructed from small, reusable and collaborative components. These components are highly cohesive and loosely coupled. Each component can be individually developed, tested, deployed, updated and managed with minimal or impact on other components.The components can be composed into an application and deployed.

OSGi Bundles

An application module or component is termed as a bundle in OSGi. Bundles are the common Java jar files except that their Manifest file contains more OSGi specific details like a definitive name, version, dependencies and other deployment details.

As opposed to normal Java application which is packaged in a monolithic jar/war file bundles are logical modules that combines to comprise an application. They explicitly define which packages they export and which external packages they depend upon. OSGi framework performs bundle resolution ensuring consistency among bundles with respects to their versions and other constraints.

The OSGi specification defines a life cycle for OSGi bundles and once the bundle is deployed the bundle life cycle determines its status. A bundle can be installed, started, stopped and uninstalled from the framework following the lifecycle prescribed by the OSGi specifications.

OSGi Containers

OSGi based application run within an OSGi Container. Following are some of the popular OSGi containers:

· Eclipse Equinox

· Apache Felix

· Knopflerfish

OSGi Benefits

· Changes are easy to accommodate:

Functionalities of a bundle are known only through its published interfaces. This allows changes to the implementation logic without affecting other collaborating bundles.

· Improved work distribution:

An OSGi based application is a collection of bundles. Each bundle defines a set of dependencies to other bundles. The development tasks can be distributed easily based on the bundle dependency hierarchy.

· Improved Testability

Each bundle can be tested as a cohesive unit in addition to the unit and integration testing.

· Improved Packaging and Release management

Application features can be developed under separate bundles. For an installation a deploy time decision can be made to package and deploy only those bundles which are relevant to the application features to be made available.

· Increased Reusability

Functionalities of a bundle can be abstracted enough to make them reusable across projects. It is even possible to reassemble module selection of an application to produce a different application.

In this article I touched upon what is OSGi and what benefits it offers. In the next article I would like to touch upon the challenges in developing an OSGi based application and how Spring DM server comes to the rescue.

Following are some of the good reference books for starting with OSGi

1. Modular Java by Craig Walls

2. OSGi in Action

Monitoring Java enabled resources either in distributed or non-distributed environments would have been thorny without JMX. What JMX technology does is that, it exposes these Java resources to be monitored using MBeans or Managed Beans. MBeans are JavaBeans really which represent the Java resources to be monitored and which can be accessed in the J2EE server. Exposing these resources as MBeans allows instrumentation. Consider a typical scenario, where Java developers troubleshoot database connection leaks, which is hard to troubleshoot. But imagine how much relaxing a Java developer would feel if  the developer could see total number of connections being opened and closed while the application is running using some graphical tool.  JMX technology provides set of tools and APIs, using which one can monitor the JVM resources.

jconsole

If you have installed J2SE 5.0, you already have a graphical tool knows as jconsole. This tool allows us to monitor local and remote JVMs. As discussed already, the technology responsible for all this is the JMX technology.

As said already, MBeans represent JVM resources. First of all, an MBean needs to be registered in the MBean Server. Also, all the MBeans need to have an object name of type javax.management.ObjectName. The JVM application which needs to be monitored provides the MBean Server to the JMX client. Now a tool, such as jconsole (JMX Client) simply connects to the MBean Server, to allow us to monitor the JVM resources.

Database Connection Pooling

Database connection pooling allows us to reuse connections. Bugs in connections are common, when some thread that demands the connection does not return it to the pool, by failing to close the connection after it does it's job. Obviously we need a monitoring tool, which can show the information related to connections, and we can then monitor how the pool is being utilized, and hence find the defective parts of the program. 

Hibernate session factory statistics

Hibernate 3 provides, lot of statistics related to the session factory. We need to  enable the statistics for the session factory first. The MBeanServerFactory can allow us to access MBeanServer. After creating an instance of StatisticsService (the MBean you want) and giving it the MBeanName , you can register the MBean. Now once you have registered the MBean, you can call various methods on it and retrieve useful information which could range from number of sessions being opened or closed or total number of cached queries successfully or find the performance related to with your queries. All this information helps you to troubleshoot and optimize things in a great way.

How to monitor your web application running locally under Tomcat using jconsole

In Tomcat 5.0 and later versions, JMX support has been enhanced to a great extent. Apart for connection leakages, developers would want to monitor their application in terms of memory usage, garbage collection, total classes being loaded, and other vital information related to queries, which would allow developers to optimize their application. Below are simple steps how one would go about making the web application running under Tomcat  to be monitored from jconsole in Windows environment. 

1- To enable the local JMX agent, you can set CATALINA_OPTS for JMX (please see below Useful links) in the Tomcat startup script.

2- Start Tomcat and access your web application.

3- Run the jconsole utility and you will see that it has detected all Java applications running locally.

You can also use jconsole <pid> where pid is the process ID of the running JVM. For example see the Windows task manager for Tomcat process ID.

4- Now access different parts of your application to see how jconsole shows the information in various tabs.

5- To monitor the MBean registered in the MBeanServer click on the "MBean" tab of jconsole, and you can see how many sessions are being opened and closed as your application flows. You can also see statistics related to your queries. There is lot of statistics available there, and the scope for monitoring is enormous. Besides all these, you will surely want to see how your application utilizes memory by using the "Memory" tab in jconsole.

Useful links:

http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html
http://www.hibernate.org/216.html
http://irserver.ucd.ie/tomcat-docs/monitoring.html

Interesting post from Byron Deeter on Sandhill where they studied more than hundred SaaS companies and came up with following laws for building highly successful SaaS businesses.

• Key business metrics for SaaS companies should be CMRR (Contracted Monthly Recurring Revenue) and Cash and not bookings
• It takes at least $300K of CMRR to climb the Sales Learning Curve - Stop at three sales reps until at least two of them are making $100K MRR quotas.
• As soon as you have climbed the Sales Learning Curve, begin ramping your sales force by hiring renewal-oriented account managers.
• Channels are very hard for SaaS companies to build, so do not base your plan on SIs and traditional ISVs. You will need to sell directly for a long time.
• Stay local - Prove your business in your market first.
• Invest early in backup and disaster recovery, but stick to one data center till listing
• Single instance, multi-tenant - Have only one version of the code in production. Say no to on premise deployments
• Savvy online marketing is a core competence (sometimes the only one) of every successful SaaS business.
• Constantly trade off cash vs. growth
• SaaS requires R&D and sales expense up front for a multi-year stream of revenue, so it demands enough investment capital to fund 4+ years of runway

Thoughts worth pondering for companies already having SaaS delivered products or planning for it.

At e-Zest, we have been providing similar kind of recommendations to our customers as part of SaaS delivery consulting services  and its quite satisfying to see that research findings are in line with what we have been recommending for quite some time .

For complete post of Byron Deeter, please refer http://www.sandhill.com/opinion/editorial.php?id=176