Thursday, July 2, 2015

Unresolved Webapp Library references

Unresolved Webapp Library references See http://docs.oracle.com/cd/E13222_01/wls/docs92/programming/libraries.html

If your webapp requires a specific version of a library, you can use the container-descriptor/prefer-application-packages/package-name clause in the weblogic.xml of your webapp. But then you should also refer to the library specific version with another clause:

   <library-ref>
      <library-name>jax-rs</library-name>
        <specification-version>2.0</specification-version>
        <exact-match>false</exact-match>
    </library-ref>


This is only a library-ref, so the library must be made available in the config.xml:

  <library>
    <name>jax-rs#2.0@2.5.1</name>
    <target>icr_v00_25000_localhost</target>
    <module-type>war</module-type>
    <source-path>/path/to/yourlibrary.war</source-path>
    <security-dd-model>DDOnly</security-dd-model>
    <staging-mode>nostage</staging-mode>
    <plan-staging-mode xsi:nil="true"></plan-staging-mode>
    <cache-in-app-directory>false</cache-in-app-directory>
  </library>




otherwise you will get the dreaded "Unresolved Webapp Library references for ...."

On the whole I find these classloader and version issues an extremely uninteresting topic...

BEA-141196 The managed server could not update the configuration files during the registration with the deployment service



<Jul 2, 2015 10:31:52 AM CEST> <Error> <Management> <BEA-141196> <The managed server could not update the configuration files during the registration with the deployment service. The update failed due to an exception:
weblogic.management.DeploymentException: Exception occured while copying files
        at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.doUpdate(DataUpdate.java:307)
        at weblogic.deploy.internal.targetserver.datamanagement.ConfigDataUpdate.doUpdate(ConfigDataUpdate.java:102)
        at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.update(DataUpdate.java:72)
        at weblogic.deploy.internal.targetserver.datamanagement.Data.commitDataUpdate(Data.java:118)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.updateFiles(RuntimeAccessDeploymentReceiverService.java:880)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.handleRegistrationResponse(RuntimeAccessDeploymentReceiverService.java:728)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.registerHandler(RuntimeAccessDeploymentReceiverService.java:699)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.start(RuntimeAccessDeploymentReceiverService.java:169)
        at weblogic.t3.srvr.ServerServicesManager.startService(ServerServicesManager.java:462)
        at weblogic.t3.srvr.ServerServicesManager.startInStandbyState(ServerServicesManager.java:167)
        at weblogic.t3.srvr.T3Srvr.initializeStandby(T3Srvr.java:881)
        at weblogic.t3.srvr.T3Srvr.startup(T3Srvr.java:568)
        at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:469)
        at weblogic.Server.main(Server.java:71)
Caused By: java.io.FileNotFoundException: /acme/appsrv/domains/pippodomain/config/pref/preferences.xml (Permission denied)
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:194)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:145)
        at weblogic.utils.FileUtils.writeToFile(FileUtils.java:115)
        at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.copy(DataUpdate.java:265)
        at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.copyOrExtractTo(DataUpdate.java:202)
        at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.updateLocalData(DataUpdate.java:168)
        at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.doUpdate(DataUpdate.java:299)
        at weblogic.deploy.internal.targetserver.datamanagement.ConfigDataUpdate.doUpdate(ConfigDataUpdate.java:102)
        at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.update(DataUpdate.java:72)
        at weblogic.deploy.internal.targetserver.datamanagement.Data.commitDataUpdate(Data.java:118)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.updateFiles(RuntimeAccessDeploymentReceiverService.java:880)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.handleRegistrationResponse(RuntimeAccessDeploymentReceiverService.java:728)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.registerHandler(RuntimeAccessDeploymentReceiverService.java:699)
        at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.start(RuntimeAccessDeploymentReceiverService.java:169)
        at weblogic.t3.srvr.ServerServicesManager.startService(ServerServicesManager.java:462)
        at weblogic.t3.srvr.ServerServicesManager.startInStandbyState(ServerServicesManager.java:167)
        at weblogic.t3.srvr.T3Srvr.initializeStandby(T3Srvr.java:881)
        at weblogic.t3.srvr.T3Srvr.startup(T3Srvr.java:568)
        at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:469)
        at weblogic.Server.main(Server.java:71)




If you look in Oracle Support, you get a Document "Error Starting WebLogic Server: BEA-141196: The managed server could not update the configuration files during the registration with the deployment service (Doc ID 1461960.1)" advising to change the rights of those files/folders to be updated.

In our case the reality was MUCH more diabolical: the managed server was contacting the ADMIN of ANOTHER DOMAIN which was mistakenly configured to run on the same box with the same admin port.... so the WRONG admin was updating the configuration of the Managed Server, even if it was belonging to a different domain.

So the solution is just to make sure that each domain runs with unique ports. It's a bit crazy that the Managed Server was accepting communication with a different domain...

Wednesday, July 1, 2015

Specifying javac debug flags in Maven

If you have the disgrace of using Maven in your project, you might be also unhappy about the fact that javac compilation is done using the standard debug flags

http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html

-g:{keyword list}

source Source file debugging information
lines Line number debugging information
vars Local variable debugging information


so passing -g:{source,lines,vars} activates the MAXIMUM debug info in the compiled classes.

Hew to pass these flags using maven is explained here http://stackoverflow.com/questions/14920921/how-to-pass-j-options-to-javac-through-maven , i.e. just add to your pom.xml this splendid XML and try not to puke for XML indigestion:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <compilerArgument>-J-g:{source,lines,vars}</compilerArgument>
    </configuration>
</plugin>