Devbits

Scala sources compile to class files that can run on JVM. So there is no doubt that most of Java EE development should be possible in Scala. Here is a simple servlet written in Scala.

package net.aseem.tryingoutscala.web
import javax.servlet.http._

class Payroll extends HttpServlet {

  override def doGet(request: HttpServletRequest, response: HttpServletResponse) =

    response.getWriter().println("Hello World")

}

What is yet not available is a reasonable IDE for Scala based Java EE application development. There is a Scala plugin for Eclipse that works great for Scala applications. So I went ahead and used it along with another plugin to get an effective Java EE development environment for Scala. I used Oracle Enterprise Pack for Eclipse (formerly know as WLS Tools) along with Scala Plugin for Eclipse to develop and deploy aforementioned Scala servlet. I installed these plugins on Eclipse IDE for Java EE Developers (version Ganymede) and tested the servlet on WebLogic Server 10g Release 3 (10.3).

Scala project
I created a Scala project called TryingOutScala (File > New > Project > Scala Wizards > Scala Project) an added Servlet 2.5 spec jar to it's build path (Project > Properties > Java Build Path > Libraries > Add External JARs). I added the jar from WLS installation at BEA_HOME/modules/javax.servlet_1.0.0.0_2-5.jar. Then I created the above mentioned Scala servlet in this project (File > New > Other > Scala Wizards > Scala Class).

Web project
Next I created a dynamic web project called Payroll (File > New > Project > Web > Dynamic Web Project) and added TryingOutScala project to it's Java EE module dependencies (Project > Properties > Java EE Module Dependencies). To web.xml of this project (located in WebContent/WEB-INF) I added the servlet from the Scala project.

<servlet>
  	<servlet-name>Home</servlet-name>
  	<servlet-class>net.aseem.tryingoutscala.web.Payroll</servlet-class>
</servlet>
<servlet-mapping>
  	<servlet-name>Home</servlet-name>
  	<url-pattern>/</url-pattern>
</servlet-mapping>

Scala Library
Our Scala servlet was now ready to be deployed, except Scala compiled classes need at least one library in classpath at runtime: scala-library.jar. For my installation, this file was available at /usr/share/java/scala-library.jar. Though packaging this library inside the web application would have worked, it would have considerably increased the size of the application. So I deployed it as a shared application library using the following command:

java weblogic.Deployer -username *** -password *** -library -deploy -name scala-library /usr/share/java/scala-library.jar

This library could also have been deployed using the console.

I added the following two lines to the top of manifest file of the web project (WebContent/META-INF/MANIFEST.MF) to ensure that the deployed library is available to the deployed application:

Extension-List: scalalib
scalalib-Extension-Name: scala-library

Deployment & Testing
To deploy the Scala servlet, I first added my local WLS installation to the available runtimes for the IDE (Window > Preferences > Server > Runtime Environments). After this was done, Payroll project was deployed by simply running it on the server that had just been added (Run > Run > Run on Server).

With WebLogic Server 10.3, there have been some changes in deployment descriptor schemas. This post discusses some of the issues that we faced in maintaining multiple loosely related XML schemas and how we tackled them. Note that none of these changes require changes to deployment descriptors. As always, old applications would continue to deploy and run without any change.

Old Namespace
We started off with a shared & stable set of schema in 9.0, all of which shared a common namespace URI: http://www.bea.com/ns/weblogic/90. Since then we haven’t made any incompatible changes to the schemas, and making any such change seems unlikely. However, the schemas do change across major releases, minor releases and even in maintenance packs. Such changes are almost always independent of each other, that is, it’s highly likely that only one of the schema document changes.

The main problem with http://www.bea.com/ns/weblogic/90 was that it included version information. When schema changes were made for a minor release or for a maintenance pack, we had to update the namespace for that schema. This was usability issue. In such a release, when an application developer wrote new descriptors, she had to deal with similar looking but different namespaces.

We could come up with a solution to schema versioning without changing the namespace within a major release, but we would still have to change the namespace once the schema changes happen for the next major release. This was a tooling issue. An application developer who performed pre-validation on her descriptors would have to change her descriptor to use the new namespace. This was also a maintenance issue for us. Each time we changed the namespace, we had to change our internal components that took care of backward compatibility.

The old convention also forced the same namespace on all the schemas. This contributed to the usability issue mentioned in the previous section. Also, it added to maintenance by forcing us to move the unchanged schemas to a new a namespace, every major release. This model did not fit well with modularity either. As teams owning the schemas spread out, we would need extra communication and co-ordination to avoid type name collisions for new types being added.

New namespaces
With WebLogic Server 10.3, all schemas now declare their own namespaces, none of which have any version in namespace URI. The general pattern of new namespace URIs is http://www.bea.com/ns/weblogic/. For example, the namespace URI for weblogic.xml is http://www.bea.com/ns/weblogic/weblogic-web-app

This change addresses the two major problems and lays out a road map for schema versioning in the future. This will help the schemas evolve independently. Representing an entire namespace in one schema also provides a cleaner extensibility model for our application developers and ISVs.

In general, namespace URI wouldn't be changed even across major releases, unless drastic changes occur and we are forced to introduce incompatible changes. Again note that even if drastic changes to schema force us to change the namespace URI, old applications would continue to work without any change.

For documentation and referencing, we do need to capture the version information of the schema, inside the schema. This is done using the “version” attribute of element at the top of each schema:

<xsd:schema ..

  version=”1.0”>

..

</xsd:schema>

We also introduced “version” attribute at the root element of each descriptor. This is somewhat similar to the version attribute for each of the Java EE descriptors. The Java EE descriptors version attribute is required and is an enumeration of supported versions. But we are not strict about this because our parsing infrastructure does a good job of in-memory conversion of document into the latest schema structure. Also, our schemas are revised more often than those of Java EE. So introducing an enumeration of possible values would be cumbersome to maintain in the future. Hence, our version attribute is optional and and of string type. Containers might use this value in the future. Here is how this would look in a descriptor:

<weblogic-web-app version=”1.0”>

..

</weblogic-web-app>

Schema Locations
Each version of every schema is published on the web for reference. The same location may also be used for schema validation in case an XML parser or editor honors schemaLocation attribute. To get the URL for a given version of any schema use the namespace URI as a URL and visit this URL using your browser. An index of various versions for that schema would show up. Each of these entries links to the published schema for that version. For example, if you visit http://www.bea.com/ns/weblogic/weblogic-web-app you would find link to version 1.0 of this schema pointing to http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd

In due course, the schemas would be migrated from BEA domain to Oracle domain. The namespace URIs themselves might be changed too, for branding and consistency purposes. But the pattern of namespace URIs would continue to be the same. Whenever these changes happen, they'll be duly documented.

(Picture licensed from Brian Marco under Creative Commons)