Devbits

Temporary files for application deployment

2009-07-24T17:49:00Z

After a user issues a deployment command, the application is whisked away by the deployment sub-system across the cluster to the appropriate managed server for deployment. We have often been asked questions about the fate of application file beyond this point and most of these questions are the in context of security manager configuration. Here is a brief overview of temporary files that are used during deployment of applications.

After handling the staging, the deployment sub-system hands over the file to containers for deployment. The containers assume the file to be available on the same machine and deal with it accordingly.

Archived applications are exploded in a sever-specific temporary directory and only the temporary location is looked at by the class loader. Exploded application directories are not copied to temporary directory. So the class loader for such an application directly looks up the original location. If such an exploded application has some archived modules (say web module), then they are exploded in a temporary directory as described earlier.

Jar files need not be exploded and are directly used by the class loader. But, for Windows, they are copied to a temporary directory and the class loader looks up the jar from the temporary location. This special treatment is done for usability as it lets users overwrite jar files.

Resource filtering configuration

2009-07-24T00:10:19Z

WebLogic Server introduced the concept of filtering class loader with release 9.2. Filtering class loader is used to filter class loading requests by application. It is configured using prefer-application-packages element in weblogic-application.xml. This configuration also modifies resource loading behavior to some extent. It has been explained in resource loading order section of the documentation.

With release 10.3.1, filtering class loader now supports a more fine grained control over resource loading behavior. A new element prefer-application-resources may be used to configure a resource pattern to filter. If this pattern is configured, any resource lookup whose URI matches the pattern will only be looked up in the application.

Consider an application flight.ear that has a jar file in it's APP-INF/lib directory and assume that this jar file contains META-INF/foo.xml. Further consider another jar file in the system class path that too has META-INF/foo.xml. If the application code uses ClassLoader.getResource(String) or ClassLoader.getResources(String) it'll see the resource from the system class path. But if the application were configured using prefer-application-resources element in weblogic-application.xml, the above resource lookup requests wouldn't find any resource from the system class path:

META-INF/foo.xml

getResource with no filtering configuration
Resource from system class path

getResources with no filtering configuration
Resource from system class path
Resource from the application

getResource with above filtering configuration
Resource from application

getResources with above filtering configuration
Resource from application

Please note that resource-name element supports “*” wild card pattern. So we could have used something like “META-INF/*” as resource name as well.

In case the resource being looked up does not match the pattern configured using prefer-application-resources, the look up behavior reverts to the default resource loading behavior of filtering class loader, as described here. If prefer-application-packages is not declared, then resource loading behavior would revert to java default.

(Picture licensed from Roshnii under creative commons)

Configuring context root for web application libraries

2008-12-22T18:05:43Z

There are many ways to configure context root for web applications and modules in WebLogic Server. There are rules around context root configuration of shared web application libraries too. This post intends to put all these configuration settings together. To read more about shared Java EE libraries supported by WebLogic Server, please refer to the documentation.

To begin with, let's go through context root configuration in non-library scenarios.

1. When a standalone web application is deployed, the context root is the file name sans the .war suffix. This can be overridden by the use of setting in weblogic.xml. In such cases the configured value is used.
2. When an enterprise application is deployed without application.xml, enclosed web modules are deployed with context root of module URI sans the .war suffix. This scenario only works with release 10.0 (Java EE 5) onwards. On earlier edition, such an application would not deploy.
3. When an enterprise application is deployed with application.xml no module scanning is performed. The declared web modules are deployed with the value from the declared element in application.xml. This element is mandatory according to schema for application.xml. This configuration would override any declaration in weblogic.xml of the module.

WebLogic Server supports the use of shared web application libraries that can be referred to from any of the following:

1. Enterprise applications or shared enterprise application libraries
2. Web applications, web modules or shared web application libraries

The meaning of such a reference is different in the two cases. The former implies that the referred shared web application library be added as a module to the enterprise application artifact. In doing so, context-root of this web module is set to the library file name sans the .war suffix. Therefore, any declaration in weblogic.xml is ignored. This behavior can be overridden:

1. While referring to a shared web application library using element in weblogic-application.xml, an optional element may be used. This declaration ensures that the context root of the library web module is set to the configured value.
2. setting in may be further overridden by the use of element in weblogic-application.xml. This overriding configuration element has been added to cater to 3rd party library scenarios. Say customer app A.ear refers to vendor library V.ear which in turn refers to another vendor library V.war. Since customer has no control over declaration in V.ear, gives her a way to override context root for V.war.

When a web application, module or shared library refers to a shared web application library, the latter is merged into the former. In such cases, declaration in weblogic.xml of the library is ignored. declaration in of weblogic.xml is also ignored.

Further clarifications
After I sent out the compilation of these rules to a colleague of mine, Konstantin Komissarchik, he wrote back requesting a few clarifications. I though it'll be useful to share his queries and my responses in this post.

Q. Could you confirm that the library name (as specified in manifest or at deployment) is not considered here and that the starting value is always based on library file name?
A. Yes, the name is NOT considered.

Q. What about the exploded web library case? Is that even supported?
A. It is supported and the same rules apply as archived shared web application libraries.

Q. Could you confirm that library-context-root-override is more generic than just the above scenario? Let's assume an EAR referencing libraries that don't reference other libraries. Can library-context-root-override be used instead of context-root element of library-ref when referencing a war library?
A. No. only overrides of . It's not good by itself. In your scenario, you'll have to use under .

Q. Can library-context-root-override be used when referencing ear library to override context roots of contained web modules?
A. No. In fact there is no such configuration that could be applied to enterprise shared library reference that would override configuration for all modules.

Q. If you have A.ear referencing library B.war, and you have specified in element for B.war, can you then override that context root using in the same
weblogic-application.xml file? Or can only override declarations from indirect references.
A. Yes, you can apply to a context-root declared in declaration of of the same weblogic-application.xml

Q. Are there any nesting limits on how deep of a reference you can override? Say you have A.ear which references library B.ear which references C.ear which references D.war and specifies . Can you use element in A.ear to change the context root that D.war is mapped to?
A. There are no nesting limits on libraries. So there is no nesting limit for this override. In this scenario, the use of would work.

Q. Is it possible to use in an EAR library (rather than EAR application)? In the scenario described in #2 above, can be placed in B.ear or C.ear and have the same effect of placing it in A.ear. If the answer to this question is yes, what happens if you want to override again in A.ear? Is that allowed? If yes, are you overriding the override or the original value specified in the element.
A. The schema of weblogic-application.xml is the same for enterprise applications and shared enterprise application libraries. So the presence of is allowed in weblogic-application.xml of shared enterprise application libraries. But it is ignored.

(Picture licensed from Athanasius under Creative Commons)

Schema Namespaces

2008-08-29T21:35:02Z

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:




  version=”1.0”>

..

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:

..

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)

Scala Servlet development

2008-08-05T15:00:00Z

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.


  	Home
  	net.aseem.tryingoutscala.web.Payroll


  	Home
  	/

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).

Faster console with WebLogic Server 10.3

2008-08-01T03:00:00Z

I tend to use more of command line tools for WebLogic Server administration. But I do use console especially when I am examining and debugging domains on remote machines. It's great news that WebLogic Server console has become much faster with this release. And the configuration locking mechanism is now implicit in development mode. So I can simply go ahead and make the configuration changes without having to explicitly acquire locks.

This video captures how fast the console works on my laptop. It's a Pentium M 1.8GHz with 2GB RAM running Windows XP SP2. I installed WebLogic Server 10.3 on it, created a new domain and started domain's admin server. In this video, I used the console to deploy and monitor a simple web application.

Out of the (browser) box

2007-05-15T22:56:12Z

There were a lot of sessions about Rich Internet Applications at the recent Web 2.0 Expo & JavaOne conferences. The poster children frameworks of "Web 2.0" have been the JavaScript libraries that have made web sites slicker. However there is a new breed of frameworks that promise the experience of desktop, the connectivity of Internet & the ease of web development. Some of the possible advantages that such applications offer over traditional browser based web applications are:

Offline Access: The often used argument for offline access doesn't stand any good in an increasingly connected world. However, the ability to buffer data in the background to cover up for network jitters makes a good case for usability.

Local Resources: Applications running from within the browser have restrictions on what they can access on the local machine. They also have limitations in terms of how much can they store temporarily in cookies. Outside the browser, all these restrictions are mostly gone. The applications can cache more data for better performance.

Better Push: A lot of web applications have alerts as an integral part of application workflow. With desktop applications, it's possible to have a lighter mechanism to alert the user than requiring her to keep the browser running at all the times.

User Controls: Multimedia applications have a better user experience if they are controllable by non-standard user inputs like volume and channel controls. This is usually not possible from within the browser.

Data Integration: An application running on the desktop has direct access to local data (like other resources). So they are more suited to mashup a user's online data with the local data. Even if local data is not involved, a desktop is a better place to mashup personal data from two different services.

There is no doubt that the experience could be functionally better for the end-users. But, using any application built on such frameworks would need some form of deployment on the customer desktop. Compare that with the web applications that need no deployment. It'll be interesting to see how the end-users take to this.

Inferring Application Configuration

2007-05-04T19:36:20Z

JEE 5 makes most of the deployment descriptors optional. For example, the annotation @Stateless can be used to identify a stateless session bean instead of adding a declaration in META-INF/ejb-jar.xml of an EJB module. To add to this, WebLogic Server 10 has extended the JEE annotation support to include annotations that make web module’s deployment descriptor optional. For example, the @WLServlet annotation can be used as an alternate for declaration in WEB-INF/web.xml. Finally, the JEE Spec has made the META-INF/application.xml optional in an enterprise application. In case META-INF/application.xml is absent, the app servers are required to examine the contents and make inference about their types. For example, a module ending with “.war” must be interpreted as a web module and should be deployed as one.

With configuration scattered around in source files and packaging details, an administrator might want to examine the consolidated configuration. The developer of the application might also want to examine the container’s view of the configuration for debugging. Two of the build time tools packaged with WebLogic Server help the administrators & the developers do exactly this. Both AppMerge & AppC now support a new flag “writeInferredDescriptors”. When this flag is used, these tools write out an updated version of the descriptors that include the configuration information from annotations and packaging. In case, the descriptors does not exist in the source application, these tools write out new descriptors if the flag is used.

Let’s assume we have an application flight.ear that has no descriptors. It has two archived modules:

$ jar tf flight.ear
statusApp.war
statusCheck.jar

Let’s assume that statusApp.war has no descriptors and has one Servlet that is annotated with @WLServlet annotation.

$ jar tf statusApp.war
WEB-INF/
WEB-INF/classes/
WEB-INF/classes/weblogic/
WEB-INF/classes/weblogic/examples/
WEB-INF/classes/weblogic/examples/flight/
WEB-INF/classes/weblogic/examples/flight/Status.class

Let’s assume that the statusCheck.jar has no descriptors either. It has some class files, one of which is a Stateless session bean that’s annotated with @Stateless & @Remote annotations

$ jar tf statusCheck.jar
weblogic/
weblogic/examples/
weblogic/examples/flight/
weblogic/examples/flight/FlightCheck.class
weblogic/examples/flight/FlightCheckBean.class

If we were to invoke AppMerge in the following way, it’ll generate a new version of flight.ear, called flightX.ear.

$ java weblogic.appmerge -writeInferredDescriptors -output flightX.ear/ flight.ear

(In this example, I appended a ‘/’ at the end of flightX.ear so that the tool creates the output application as a directory. We could drop the '/' in the end (-output flightX.ear) and the tool would generate an archive.)

If we were now to examine flightX.ear, it’ll have a deployment descriptor.

$ cat flightX.ear/META-INF/application.xml


  
    
      statusApp.war
      statusApp
    
  
  
    statusCheck.jar

Similarly, the two modules in flightX.ear would now have descriptors:

$ jar tf flightX.ear/statusApp.war WEB-INF/web.xml
WEB-INF/web.xml
$ jar tf flightX.ear/statusCheck.jar META-INF/ejb-jar.xml
META-INF/ejb-jar.xml

These descriptors can now be examined to see how the containers would deal with the module deployment. Note that the descriptors in the modules would have “metadata-complete” attribute on the root element set to true.

The flag "writeInferredDescriptors" can also be used for deployment optimization. If we were to deploy flightX.ear, the annotation processing would not be done because metadata-complete is set to true. Module discovery wouldn’t be done either because META-INF/application.xml would now be present in the application.