Mark Gargin

Hey folks,

I've encountered a bit of a problem with using log4j's MDC class within applications in weblogic. It's not a bug at all it's just giving me grief.

Basically I've setup ApplicationLifecycleListener on my ear app and on all web apps within weblogic. They're there to catch startup events so that I can slot the application name into the MDC in order to be able to retrieve it when an exception occurs.
Web :-
MDC.put("APPLICATION_NAME", ce.getServletContext().getServletContextName());
EJB :-
MDC.put("APPLICATION_NAME", evt.getApplicationContext().getApplicationName();


Alas as the lifecycle listener events are handled on a seperate thread where exceptions occur the MDC, being effectively a threadlocal hashmap, returns null when I attempt to retrieve the name of the app.

I was wondering if anyone could think of a cleaner way of doing this? Perhaps using JMX or even by binding the contextClassLoader (which seems to remain the same across the threads into the JNDI tree with the application name)? Or else if anyone can think of any neater way of doing this that would be great.

Thanks,
Mark.

Hey folks,

I have a weblogic-application.xml file that looks like the following

<?xml version="1.0"?> <!DOCTYPE weblogic-application PUBLIC "-//BEA Systems, Inc.//DTD WebLogic Application 8.1.0//EN" "http://www.bea.com/servers/wls810/dtd/weblogic-application_2_0.dtd"> <weblogic-application> <application-param> <param-name>APP.NAME</param-name> <param-value>myejb.ear</param-value> </application-param> </weblogic-application>

It's used at runtime to identify from which application an exception is thrown. ( Perhaps this is not the way to do this?? ) I was wondering how I go about retrieving the value of the param from a java class within the app.
it's probably going to be an ApplicationLifecycle class.
Would it be something like

new InitialContext().lookup("java:comp/env/APP.NAME")

(I guess I don't think it's this as it eh.. hasn't worked for me.)

Thanks,
Mark.

Hey folks,

I'm attempting to port our product from Websphere to Weblogic. With Websphere we use the shared libraries functionality to specify a folder on the filesystem which is prepended to the classpath of the application at runtime. We locate a lot of config property files in there.

I've looked for the equivalent in weblogic but haven't been able to locate it as of yet? I'd prefer not to hardcode a folder to the weblogic server command line cos that's a bit of hack. Would anyone know if there is an equivalent in weblogic?

Thanks,
Mark.

Hi folks,

Have been toiling with this problem for a couple of days now. Basically it all boils down to the scope of local references between beans.

I have two beans. One references the other. I've read in a couple of places that the requirement for local reference use is that the two beans must be in the same jvm. And then a few lines later they've specified that they must in fact be in the same ear file.

I've managed to get a local reference between beans where the beans are deployed in seperate jars but within the same EAR file. However the way our project is divided, this places an unwanted dependancy between teams.

Would anyone know if two beans in separate ear files but in the same jvm (Maybe the problem is my presuming that weblogic doesn't kick off a seperate jvm per deployed ear file.... say it ain't so!!!)

If indeed it is possible, could someone supply the appropriate deployment segements from the ejb-jar.xml and weblogic-ejb-jar.xml that allows this local reference? Am going a shade spare.

Thanks,
Mark.

Hi folks,

I just posted a quick question about jarEntry loading. I'm trying to put together a JarClassloader that allows you to run an application completely from within a jar app. It is basically an extension of Simon tuffs excellent one-jar application that can be located here.

http://one-jar.sourceforge.net/

Without this application I'd never have gotten close to figure out how to use the JAR API never mind attempt to put something like this together.

I'm getting to the stage where I have to decide on a pattern for loading internal jar files and their resources. I'm not too familiar with patterns so I was hoping maybe we could bandy about a few ideas as to what would be the proper, safest, fastest way to load classes and their resources.

The following archive structure gives a brief example of what I'm trying to achieve
jarA.jar | |--->META-INF/MANIFEST.MF |--->com/my/classes/ClassA.class |--->lib/jarB.jar | |--->META-INF/MANIFEST.MF |--->com/classes/my/classes/need/ClassB.class |--->config/log4j.properties |--->log4j-1.2.7.jar |--->utils/jarC.jar | |--->META-INF/MANIFEST.MF |--->com/classes/my/library/classes/need/ClassC.class | |--->jarD.jar |--->com/classes/my/classes/need/ClassD.class

[edit] sorry the indentation of the jar structure was removed and I only noticed a couple of hours later.


So basically from the structure, ClassA requires ClassB and ClassB requires classC and so on.

The current JarClassLoader implemented parses the manifest of jarA.jar. One jar that is an entry of another jar e.g. jarB.jar in jarA.jar
will only be loaded if it is declared in the Manifest of the containing archive. Otherwise it is skipped and a warning is thrown.

It catalogs and loads any classes/resources that it finds in the initial jar, jarA.jar. Any internal jars it comes across, i.e. libs/jarB.jar it also catalogs and loads any classes within. Within the process of cataloging jarB.jar if it encounters a further inner jar i.e. jarC.jar, it
extracts it to the file system to a temp dir and catalogs it. I understand that this extraction is not perfect but try as I may I
couldn't get an inputstream to 2nd level embedded jar without extracting it.

The difference between cataloging and loading is simply that cataloging a resource simply records in memory where the resource can be found.
Loading involves retrieving the actual bytes into memory. As of today I've decided to simply load the resources in the root of the initial jar
i.e. jarA.jar and solely catalogue the resources for a further two levels of archiving, and from this employ lazy loading for any class/resource files
that don't reside as entries of the initial jar.

i.e. load classes/resources from jarA.jar but only catalog resources from jars B & C.

By cataloging, a treemap is created mapping packages and resources to locations.
By loading, a resourceByteCode repository is created with byte arrays and codesources associated with loaded resources.

Loading classes
=================
When a class is requested, the classLoader queries the resourceByteCode repository and if it's already loaded then it returns the bytes.
If not loaded it checks the tree map to see if it has been catalogued. If so the location is retrieved from the tree and the class is
loaded from the archive where it was first encountered in the cataloging. i.e. if ClassA appeared in both jarA and jarB , the version
located in jarA would be loaded.

Loading resources such as Property files
========================================
In terms of resources such as property files or basically anything retrieved using Thread.currentThread.getContextClassLoader().getResource() method,
currently if the resource appears on the classpath of the java command i.e. java -classpath then it is loaded from there first. I understand this is not
what is meant by standalone jar but a developer may wish to override resource files without recreating the jar.
If the resource doesn't exist on the classpath then the stacktrace to the method call is descended until we arrive at the class where the resource was requested. The resource location for this class is retrieved and the resource is only searched for within this archive.
For example, ClassB uses log4j. A request from this class for the resource config.log4j.properties is successful as the props file is
located in the same archive.
If however, ClassC was to attempt to load config.log4j.properties then it will fail as it seems more appropriate that much in the same way that
superclasses should never know about their subclasses attributes, in a situation where Application B is built using Application C, App C should have
no reason to be aware of any of the resources App B.

** The resource loading section described here is still being worked on.

What is in the pipeline (I think) is a tiering of Classloaders that maintain the various levels of archive indentation i.e. the classes/resources in jars
C and D in the above example would be loaded by one classloader, the classes/resources of jarB by another and those of jarA by yet another.
The hierarchy would be parent/child starting from root jar as the sole parent. The class loading delegation model would be parent first but the
classpath of the java command will always be searched first before resorting to the JarLoading hierarchy. (this could be switched to JarLoading first
or even to a caller delegation model as described in the resource section)

Well that's the height of it at the minute. I'd love a few comments as to the loading model that should be employed
as this description has been fairly hamfisted together while my boss is out of the room ;-) If folks think it's a useless
application then I'd fully appreciate that too just please give a reason or so. A wise man on the JBoss mailing list said
there are no negative comments.

Thanks,
Mark

[ November 29, 2005: Message edited by: Mark Gargin ]

[ November 29, 2005: Message edited by: Mark Gargin ]
[ November 29, 2005: Message edited by: Mark Gargin ]

Hi folks,

I've put together a little JarLoader class as an attempt to provide a facility
for running standalone jarred applications. Basically it's an extension of Simon Tuffs one-jar sourceforge project which I can't recommend enough. It's a really great project and a wonderful introduction to the use of the JAR API.

http://one-jar.sourceforge.net

He also has a great plugin for Eclipse that allows you to peer into jars in your workspace and amend them. Top notch stuff.

My problem is this:-

I have a jar like the following.
=======================
JarA.jar
|
|-->ClassA.class
|-->JarB.jar
|
|---->ClassB.class

i.e. jarA contains the class, ClassA, and a another jar, jarB. jarB contains
the class, ClassB.

Using the jar api I can retrieve and load ClassB using the following code.

JarFile jarFile = new JarFile("jars/jarA.jar"); Enumeration enums = jarFile.entries(); JarEntry internalJarFile; while(!(internalJarFile = (JarEntry)enums.nextElement()).getName().equals("jarB.jar")) {} InputStream in = jarFile.getInputStream(internalJarFile); JarInputStream jin = new JarInputStream(in); JarEntry innerEntry ; while(!(innerEntry = jin.getNextJarEntry()).getName().equals("ClassB.class")) {} File tmpjarb = new File("jars/ClassB.class"); FileOutputStream out = new FileOutputStream(tmpjarb); copy (jin, out); out.flush(); out.close();

I've written a little catalog function that traverses a jar and catalogs all the classes that it finds. however, and this is the crux of the problem, it doesn't load them until the JarClassLoader is prompted for the class at runtime. i.e. lazy loading. I don't want to have to iterate over the entries in the internal file everytime I want to load a resource from it. The catalog function saves along with the description of the resource, the size of the resource and the offset into the archive where the resource began.

To calculate the offset, it simply increments an offset by the size of each entry it comes across during the original traversal. Alas I don't think this is giving me the correct offset value at all. When it comes time to load the resource, it finds the location of the archive, opens a JarInputStream to it and then skips along by the offset and attempts then to read the recorded number of bytes that should specify the archived entry. Alas this is not working for me.

Therefore while I can lazily load the classes I have to resort to iterating over all the entries within the archive where my resource resides. So while it's lazy it is not very fast. If I could implement this offset loading then surely it would be a lot faster especially in archives where there are hundreds of entries.

Anyone any ideas? Maybe someone is familiar enough with the JAR api to be able to recommend a better way to get the offset into the jar file? Perhaps this isn't plausible? Any suggestions are most welcome.

Thanks,
Mark.
[ November 29, 2005: Message edited by: Mark Gargin ]

Hi Paul,

The session and user I'm talking about at threadlocal variables
that are set at runtime. Do you think this is possible?

Thanks,
Mark.

Hi folks,

My application always has a tradeID associated with the session.
Is there anyway I could pass this tradeID to the conversion pattern so that
I wouldn't have to code it in the debug string each time?

session.getTradeID()

Thanks,
Mark.