Things that might very well zoom in the near future is the JDA-composer check it out.
I've been writing a Swing application with the purpose to make it quicker to prototype Java2D-code. I wanted an application that made a Graphics2D object available to a BeanShell script so that the script could draw on it. The app should then display the results. I also did not want to write an editor so the app should watch a script file for changes so that I could edit the script in jEdit.
The basic functionality is finished and works, but only for JavaScript (the Rhino engine included in JDK 1.6). Right after I've comitted the code and started looking at including BeanShell support I found Scott Violet's blog and his excelent app. Which is almost the same as mine, enough so that I put my application on hold.
Still no bloggings from my friend.
2007-10-23
2007-10-15
JCA classloading
First off. No blog sightings from my friend, it is a sad state of affairs.
Now, for something that definately does not zoom. JCA classloading. Have you read the specification yet? Many, many pages about the contract between the resource adapter and its environment. All fine and dandy. Very complex I'll grant you but still, it is described.
Then you read up on the packaging, the usual java stuff, zip files and place a magic file to configure it. So you create the RAR-file. Then you write a client. But wait! The client and the adapter shares an interface. In what archive does that go?
And that, as they say, is the question.
If you have a webapp it has its own classloader, the JCA has another. So they do not see each other. Which is mostly ok until you come to the shared code. You have to place it in a classloader that both see. Which one is that then? Place it on the classpath of the entire application server? That works of course but kind of defeats the entire point of having deployable archives lite WAR & RAR.
The only working alternative I've found is to place both the client and the resource adapter in an EAR and then totally mess about with the classloading mechanism in the application server. Both weblogic and JBoss can be coerced into some kind of hierarchy that works. But still. Why oh why couldn't the JEE specification have decided how to do this?
Now we're stuck with application server specific black magic to get the damned thing to work.
JCA does not zoom.
Now, for something that definately does not zoom. JCA classloading. Have you read the specification yet? Many, many pages about the contract between the resource adapter and its environment. All fine and dandy. Very complex I'll grant you but still, it is described.
Then you read up on the packaging, the usual java stuff, zip files and place a magic file to configure it. So you create the RAR-file. Then you write a client. But wait! The client and the adapter shares an interface. In what archive does that go?
And that, as they say, is the question.
If you have a webapp it has its own classloader, the JCA has another. So they do not see each other. Which is mostly ok until you come to the shared code. You have to place it in a classloader that both see. Which one is that then? Place it on the classpath of the entire application server? That works of course but kind of defeats the entire point of having deployable archives lite WAR & RAR.
The only working alternative I've found is to place both the client and the resource adapter in an EAR and then totally mess about with the classloading mechanism in the application server. Both weblogic and JBoss can be coerced into some kind of hierarchy that works. But still. Why oh why couldn't the JEE specification have decided how to do this?
Now we're stuck with application server specific black magic to get the damned thing to work.
JCA does not zoom.
Subscribe to:
Posts (Atom)