nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Java differences between Builder and Service

Brett_Conley

I've always expected any Java addons I create and use via JavaObject to behave the same whether I'm running in Builder or as a Service. But I've recently discovered that this is not the case. I have two issues currently that I'm aware of (because they affect me).

First, if my Java object sets up logging using Java's Logger class, it works perfectly fine in Builder. But when I run it as a service, it only outputs WARNING and SEVERE log messages.

Second, XPath doesn't work at all when running as a service. Works fine in Builder. Tracing through the exceptions, looks like it can't find the default XPath factory (at http://java.sun.com/jaxp/xpath/dom) when running as a service.

Why is there any difference at all? I've been developing this project for months assuming that everything I developed in Builder was going to work when I ran as service, and now I discover that it doesn't work at all. Help!

I have sample Java files that demonstrate the problems that I can attach if anyone wants to see them. I'll refrain for the moment in case there's just some easy little config option that will fix everything for me.

Find more posts tagged with

Comments

Robert_Haskett

Hi Brett, this has come up before in the OScript forums.

https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=29371136&objAction=viewincontainer&ShowReplyEntry=29386270#forum_topic_29386270

It seems that when the JVM is started via builder, the problem is that getContextClassLoader() is returning null. This is because in Java threads created from JNI code in a non-java thread have null ContextClassloader unless the creator explicitly sets it. So in builder, the context class loader is set but in a normal running environment, the class loader is not set.

Another thing to watch for is to make sure your jar files etc are all in the same place on both your server install and wherever you're working on your llbuilder.

.r.

Robert_Haskett

We've figured this one out ( for anyone else reading this thread ). It has to do with how JVM threads are assigned a contextClassLoader. Since Builder runs only a single thread, it attachs directly to the JVM, which already has a contextClassLoader defined. But in Server mode, we (OpenText) programatically create the JVM threads and attach them individually to our native Oscript threads. These JVM threads do not have a contextClassLoader defined by default. Any Java code that relies on the contextClassLoader to load it's dependent classes will run into an exception because it can't load whatever classes are being requested. So, for now, you will need to add a check for and set, the contextClassLoader, like so:

/*** Jaxws uses thread context classloader to load classes. Since Content Server native threads are not created by JVM, the thread context classloader is null.  Here we set thread context classloader to the application classloader to avoid NPE.*/      private static void checkContextLoader()      {            if ( Thread.currentThread().getContextClassLoader() == null )            {                  Thread.currentThread().setContextClassLoader(ClassLoader.getSystemClassLoader() );            }      }

We are investigating our internal code to see if we can change this behaviour in Content Server, but for now, the above code should fix any NPE ( null pointer exceptions ) caused by 'missing' classes.

The second part of this thread, the logging issue, is because the OML.jar file has code that sets the logger level for the rootLogger, which affects ANY java code using the logger class.

.r.