Using Subject Alternative Names in certificates

if your site can be served via more than 1 hostname, you might have to set a "Subject Alternative Name" (SAN) with a comma separated list of all your valid hostnames.

The MAD thing is that is you use a SAN, your MAIN Common Name (certificate SUbject) will be ignored. So in your SAN list you should specify also the hostname that used to go in the Main subject.

Unless you do that, you will get a "Server's certificate does not match URL" in Chrome, or a "Mismatched Address" in IE. IE really stinks because its error message gives absolutely no extra info, while Chrome gives some extra context information. Shame on Microsoft.

Chrome full message says "This server could not prove that it is bla.acme.net; its security certificate is from pippo.acme.net . This may be caused by a misconfiguration or an attacker intercepting your connection"

The RFC which could bring some order in this chaos is here https://tools.ietf.org/html/rfc6125 and search for subjectAlternativeName .

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

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>