WebLogic and libs conflicts: how to know the versions that WebLogic already has?

Navigation
3

My question is beginner, but I feel pretty lost.

I've been working with Java, but I've always used Tomcat. I recently needed to make my webapp compatible with WebLogic. The problem is that I started to have conflicting versions of libs.

After some search on the Internet, I ended up adding the file weblogic.xml and adding the tag prefer-web-inf-classes to the value true .

However my doubt is more conceptual. The question is this: how can I know what are the libs that WebLogic already offers me?

For example, if I'm developing a JSF application, WebLogic already offers me a particular lib with a certain version, right? How can I know this version (JSF is an example, but I would like to know all that is available to me)? And later, if I used maven in this JSF application, should I use scope provided in the dependency definition?

I hope the issue has not been too confusing. If so, please ask me for more information in the comments.

    
asked by anonymous 28.07.2015 / 13:23

1 answer

1

Answering each question would look something like this:

How can I know what libraries WebLogic already offers me?

The version of the libraries will depend on the container version, as it will depend on the support the container

For example, for version 12c 12.1.3 of WebLogic are supported these versions of standards, whereas for 11g 11.1.1.9 , these .

Should I use maven in this JSF application, should I use the scope provided in the dependency definition?

Yes, you can use this scope and no longer need to tell WebLogic to prioritize those in the application's library directory. This scope will not include the dependency on the package as it is expected to be provided in runtime by container .

In addition, one way to get your project to support multiple environments is to use maven profiles to define which and how dependencies will be managed. An example would be this: 

<profile>
    <id>tomcat</id>
    <activation>
        <activeByDefault>true</activeByDefault>
    </activation>
    <dependencies>
        <dependency>
            <groupId>javax.faces</groupId>
            <artifactId>jsf-api</artifactId>
            <version>2.0</version>
        </dependency>
    </dependencies>
</profile>

<profile>
    <id>weblogic</id>
    <dependencies>
        <dependency>
            <groupId>javax.faces</groupId>
            <artifactId>jsf-api</artifactId>
            <version>2.0</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>
</profile>

In this example we realize that for the tomcat profile we will always package the jsf-api version% library, whereas for different versions of 2.0 the library will always be "provided" by the container and may even be different version, as supported by the container and its application. That is, if we used JSF WebLogic we could bundle to 2.1.* and declare it to tomcat version WebLogic .

    
28.07.2015 / 14:24
Prepocessor (Less) - Variable @Arguments Difficulty in grouping and where clause in MySql