12 December 2011

WebLogic Server 12c - Identifying versions of modules, libraries, frameworks


Now that WebLogic Server 12c has been released, it's interesting to look at the various libraries, modules and open-source frameworks it uses.

One approach to doing this is to use the wls-cat utility to search for a known class from the framework, module or open-source framework you are interested in looking at, and observing where the class is loaded from and the corresponding library version.

JavaServer Faces

One important item to note here is that as of the WebLogic Server 12c release, the JSF implementation has been added directly to the WebLogic Server classpath.  This is a change from the WebLogic Server 11g release where the JSF implementation was provided as an optional shared-library, which needed to be deployed in order for applications to use JSF.  With WebLogic Server 12c, JSF is now an integral part of the server and can be used without the necessity of deploying and referencing the shared-library.

javax.faces.webapp.FacesServlet:


com.sun.faces.facelets.Facelet:


Using:
  • JSF 2.1
  • Mojarra 2.1.5

Java Persistence API / EclipseLink

javax.persistence.Entity:



org.eclipse.persistence.jpa.JpaEntityManager:


Using:
  • JPA 2.0
  • EclipseLink 2.3

Context and Dependency Injection/Weld

javax.enterprise.inject.Model:



org.jboss.weld.Container:


Using:
  • CDI 1.0
  • Weld 1.1.3-SP1

SLF4J

org.slf4j.Logger:


Using:
  • SLF4J 1.6.1

3 comments:

William said...

Hey Steve,
Quick question: Why OEPE facets still show JSF 2.0 ?

Also, when I create a new web project on OEPE, how to select the JSF 2.1 library ?

Anonymous said...

What do you think about the fact that they have included sl4j on the system classpath. If I am using the slf4j in a war and trying to use my own slf4j impl, the fact that they have a 2nd impl on the system classpath is a pain. In an ear I can filter their's out but in a war I can't avoid slf4j complaining about their 2nd impl even if I do prefer-web-inf=true. Why does weblogic insist on putting stuff like that on the system classpath and letting it be visible to applications?

Buttso said...

WLS uses slf4j in places so it needs it available.

Not sure if you've seen it, but there is support for setting filtering-classloader packages at the war level using weblogic.xml, in addition to the ear level.

So for the case you have describe here, that should enable you to bundle a version of slf4j in your war file and direct wls to use it.

-steve-