How we handled ADF Security

Well. we're handling it, alright.

One of the things you must take into account is that developing in JDeveloper with integrated WLS has advantages, but it can be living hell when you try to move application to standalone server. I guess development environment gives you some advantages by setting some things where they should be so you can focus on programming itself. And that is cool. What is not cool is that some of the details remain hidden from you, so you can easily overlook them.

As for ADF Security and moving it to other environments, I found this very helpfull. Andrejus gives you nice step-by-step introduction, with pointing to relevant articles and tutorials from Oracle. But...

What wasn't said, or maybe I have missed it, was that you have to put adf-config.xml file on the classpath. If you download Andrejus' example, when you make a deloyment EAR you will see that there is a directory adf with META-INF directory that has connections.xml and, most important, adf-config.xml

adf-config.xml has few things you need for using ADF Security.


Of course, you can find enough documentation on this.

And this is put to our classpath by using adf-loc.jar that is in the lib directory of EAR. This jar contains only META-INF with manifest file containing this

Manifest-Version: 1.0
Class-Path: ../adf


So that does the trick.

But, now what?

First, I don't like this restarting server part. It means that changing policies during production requires migration process and restarting server, which I think no one likes. I guess that integrating previous Oracle technologies with WLS has just begun, this has to be corrected ASAP.

Second, I guess there aren't many people whith knowledge from both worlds (Oracle and BEA), which will probably change in time. Until then, we have to handle things like this.

Anyway, I would like to thank Andrejus for his article and his lovely example that showed me the light.

Cheers!

Some trouble with AWT libraries on Linux

Our application is fine, thanks for asking. Our painfull security problem is gone, which will probably be the topic of next posto. But here is the fresh problem and a fresh solution.


Our app is using some fancy graph solutions for displaying some statistical data form the application. We are using some ADF stuff, there are some cute controls to help you with that. We are developing on Windows, so the test servers were there. So, today is the big day when I am setting up some VMs for live testing and we are using Linux on them. WLS is installed, domain configured (actually, I just copied domain folder from Windows to Linux and changed paths etc. also an interesting topic) . Server started, I go to a login page, log in, I get main window whith menus and wait for my graphs to be rendered... And the, exception printed on the console, my session breaks and I am returned to the login page!

Here are the interesting parts from stacktrace:

SEVERE: Server Exception during PPR, #1
javax.servlet.ServletException: java.lang.InternalError: Can't connect to X11 window server using 'centosbi.antegra.com:99' as the value of the DISPLAY variable

java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11GraphicsEnvironment

X11? WTF?


Google is my best friend, so I came up with some pointers quite fast:

link1

So, it turns out that if I use something from AWT, I need X environment. No way! Well, the guys suggested xvfb solution, which didnt make me very happy... But some guy suggested to set java parameter

-Djava.awt.headless=true

So I tried that. I set it into setDomainEnv.sh file like java property in line JAVA_OPTIONS=...


And it worked.


So, if you use Oracle graphical components for rendering bars, pie charts etc. on Linux, you better set this parameter.

Cheers!

Basic EclipseLink persistence.xml configuration

Right,let's start with the basics.

Weblogic has inherited from it's previous versions O/R mapping called KODO. I don't have much to say about it, but it is default ORM for Weblogic, just as Toplink was for OC4J or HIbernate is for JBoss. Of course, JPA is implemented on all of these platforms, and the implementation is done in these persistence mappers. You should try to use JPA as much as possible, and use HIbernate/EclipseLink specifics only where you don't have any other choice. Simple rule, but as always, the problem is judging when to do that. We will say more about it in some other post.

Let's get back to persistence.xml. Since default ORM for Weblogic is KODO, if you try to use persistence.xml you used on OC4J,

Here we used addidtional properties for generating tables based on our JPA entities. It can be useful in development. Of course, not in production, you don't want to drop all tables when you deploy application. Note here that on Toplink we had to excplicitly say type of databse so this would work. We also specified logging level for toplink.

Weblogic will assume that it should use default ORM, KODO. Then you will see some KODO specific messages, and things will work... To a certain point.

As it turned out, regardless of JPA standard, implementations are not perfect. The last thing you need is changing ORM in the middle of the project (believe me, Hibernate, Toplink... I know!). If you developed with Toplink so far, you should stick to what you know. So we want to stick to Toplink which meanwhile became EclipseLink. OK, you get it with new Weblogic. Now we just have to put couple more things in persistence.xml






Note couple of things. First, we had to tell Weblogic what persistence provider we want to use:

org.eclipse.persistence.jpa.PersistenceProvider

Make sure you put it right after persistence-unit tag.

Second, name of eclipselink properties are equivalent to toplink properties. Where once was toplink, now is eclipselink. Same thing goes for most of the classes, package naming etc. So all of this makes transition from Toplink to Eclipselink on Weblogic quite simple. Until we get to classloading and structuring our EAR for new platform.

That is another story.

Hope this helps someone!