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!

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!

Did you get used to WebLogic?

Last autumn it was quite a surprise for us when it turned out that after number of technical previews (four, actually) Oracle is giving up on OC4J and bringing BEA into its warm nest. Yeah, perhaps we should have listened better, or is it just me expecting that after TP1, TP2, TP3 and TP4 we get final release? Well, what's there is there. We had application in development which at some point took a turn from Jboss/Hibernate platform (it was quite a road, I tell you) and went Oracle style. In next series of posts we will describe in great detail what changing from on application server/persistence layer is like, and during last year we had two of them. Just when I was finishing the work on OC4J, big news of Weblogic coming to Oracle!

I remember that last summer there was a poll on Oracle forum. Question was if we started developing products with TP4. At the time about 54% of people said yes, and twenty something said that they are going to. It is good thing I didn't start writing this blog back then :D After some time, I can say that we're cool with our new app. server. It is not like we had any choice, but Weblogic is quite good.

Last few years I have been J2EE developer and I worked on Jboss and OC4J 10. So few words about them.

Jboss is cool. I did not use it in production, just in development, but it was fast enough, it is cheapest you can get, nice community, configuring is XML based, but no restarts needed.

OC4J 10. Well, at least it's got nce console... Not too nice, that default OC4J ADF look makes a man sick. Deployment was not flexible enough, speed, naah, and you needed to restart it quite more than you would like.

OK, then the previews came. 1,2,3,4... We had no graphic console, but I can't say that making command scripts really hurts. If you want point-click, you are in wrong business. But bugs... Jesus, Joe and Marry! Weird errors, null pointer exceptions when you have unique constraints, totally useless error logging... Try developing on a thing like that. You hope for a finale release, remember the old days when everything was cool. OK, not everything was cool, but I least knew what was going on.

So, what has Weblogic brought to us?

First, my favourite topic, persistence layer. We got EclipseLink now! And I am really happy! All those cool stuff we had in TopLink is now here, it's in the community, we can see source (not that I need it, but it is good feeling ;) ) , guys on the news group respond to all our stupid and not so stupid questions in reasonable time. Using it is almost out of the box, since we need to put couple more lines in our persistence.xml to override using KODO (more about this in next post), we ran into couple of bugs (easy, easy...), but I am satisfied, mostly because you can get a lot uf useful info.

I recomend this little site EclipseLink - Eclipsepedia and a news group.


Then Weblogic itself. Nice console, a lot of options for deployment, strong base of users... No wonder Oracle bought it. Not so nice thing is that old BEA forum was not avalilable when I was looking for some answers, although it was shown in Google search results, so I had to use Google cache... JMS services are more complex than we got used to. All server is, actually, around clustering and guys that were presenting us Weblogic couple of months ago were proud of that.

There are issues about compiling code (if you have generics), and structuring deployment archive. Adapting code that worked fine on Jboss and OC4J was not very pleasant thing, and the deployment archive we finally made work had quite unexpected structure. Now issues of transfering Oracle ADF security to a standalone production are main problem. We hope we will make it work... Just like everything else. I can only say for now that following instructions from Oracle site, was not enough.

Actually, it was never enough. We had to experiment a lot, got couple of times in dead end, and sometimes I had exceptions that only occured two times on Google... And no one knew answer.

I hope you had better luck. But we will be happy to share everythinig we found out so far. Maybe it will help someone (solidarity, brothers and sisters!) and perhaps some of you will have few pointers. On Monday I will start with basic persistence layer configuration and maybe few notes what doesn't work.

Well, earn your daily bread with Weblogic! It is a good life.