Weblogic and libs conflicts: how to know which versions Weblogic already has?

Asked

Viewed 659 times

3

My question is of beginner, but I feel quite lost.

I have been working with Java, but have always used Tomcat. I recently needed to make my "webapp" compatible with Weblogic. The problem is that I started having libs version conflicts.

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

However my doubt is more conceptual. The question is this: how can I know which libs Weblogic already offers me?

For example, if I am developing a JSF application Weblogic already offers me a certain 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 you use Maven in this JSF application, you should use Scope provided in defining dependency?

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

  • Which version of Weblogic? The version will define, for example, whether JSF 2.2 support is already given or not. And yes, when it comes to JEE outbuildings the scope is provided so that something is not packaged that the container already possess.

  • Good afternoon Bruno. I use Weblogic 12c (version 12.1.3, if I am not in error).

  • Includes a reply that has such version, see if it suits you.

1 answer

1


To answer every question, it would be something like this:

How can I know which libs Weblogic already offers me?

The library version will depend on the version of container, since it will depend on the support that the container gives Java EE specifications.

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

If you used maven in this JSF application, you should use Scope provided in defining dependency?

Yes, you can use this scope and no longer need to tell the WebLogic to prioritize gifts in the application’s library directory. This scope will not include the dependency in the bundled as it is expected to be provided on Runtime for container.

In addition, one way to get your project to support multiple environments is by using profiles from maven to define what 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 profile tomcat we will always pack the library jsf-api version 2.0, whereas for different versions of WebLogic the library will always be "provided" by container and may even be of different version, according to the supported by container and its application. That is, if we use JSF 2.1.* we could package for the tomcat and declare it to the WebLogic version 12c 12.1.3.

  • 1

    Well, this was exactly the answer I was looking for Bruno :) Thank you. I will mark as answered.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.