This just in:
Spring 3.1 and Grails 2.0 Released
Spring 3.1 is now available from our new maven repository or from the direct download via community download page. This release provides a significant upgrade to the Spring framework with environment profiles, caching abstraction, and Java 7 and Hibernate 4.0 support. The Grails 2.0 release is also imminent, so be sure to check the download center. This major upgrade adds a new interactive mode, console enhancements, a reloading agent, and numerous testing and error handling improvements.
More details can be found here.
SpringSource in conjunction with the No Fluff Just Stuff Symposium Series are pleased to present SpringOne 2GX, the premier Java event of 2011. SpringOne 2GX is a collocated event covering the entire Spring ecosystem and Groovy/Grails technologies.
SpringOne 2GX is a one-of-a-kind conference for application developers, solution architects, web operations and IT teams who develop business applications, create multi-device aware web applications, design cloud architectures, and manage high performance infrastructure. The sessions are specifically tailored for developers using the hugely popular open source Spring technologies, Groovy & Grails, and Tomcat. Whether you’re building and running mission-critical business applications or designing the next killer cloud application, SpringOne 2GX will keep you up to date with the latest enterprise technology.
Featuring over 100 presentations delivered by development leads and published authors on the Spring, Groovy/Grails, Tomcat and Cloud technology today, it’s the ideal place to obtain critical skills to help you build, run and manage tomorrow’s software solutions. Plus you’ll meet and learn from open source leaders who drive innovation for these technologies.
We are busy planning the event schedule. Be sure to check our website soon for more speaker and session information!
Another exciting update from our growing “News that I missed” department:
We’re pleased to an announce the release of Spring Security 3.0.5.
This release fixes a few bugs which were causing problems with 3.0.4. Please see the changelog for a full list of issues which have been addressed.
The release is available from the Spring Community Downloads area and should be available from the Maven Central repository soon.
It happened last week, but it’s still worth mentioning:
Lost somewhere in all the news and excitement about last week’s SpringOne 2GX conference was the news that Spring 3.0.5 is now available. This release addresses over 80 minor issues and includes some small improvements to the Spring Expression Language (SpEL), annotation support, and embedded databases. Be sure to read the Change Log for all the details.
The previous day, there were also new releases of Spring Security:
We’re pleased to an announce the release of Spring Security 3.0.4.
This release provides a fix for the vulnerability CVE-2010-3700. A 2.0.6 release has also been provided for users who have not yet to upgraded to Spring Security 3.
Please see the changelog for a full list of issues which have been addressed.
Both releases are available from the Spring Community Downloads area and also from the Maven Central repository.
One of the main reasons that I wanted to figure out how to put the persistence.xml file outside of my EJB jar file, aside from my desire to externalize the datasource reference, was because I wanted to share the persistence.xml across multiple EJB jars. One of the EJB jars contained a collection of shared components designed to be used by multiple applications. The other contained application-specific components that were built solely for the use of the application itself.
The database supporting the application contained all of the tables for both the common components and the application-specific components, so one datasource, and one persistence.xml file could support both EJB jars. Getting the persistence.xml file out of the individual jars and into the .ear file made that possible. With the inclusion of both EBJ jar files, the project structure now looked like this:
.ear file +- /lib directory | +- persistence.jar file | +- /META-INF directory | +- persistence.xml file +- webapp.war file +- shared-ejb.jar file +- application-specific-ejb.jar file
All that was then necessary to make the lone persistence.xml support both EJB jars was to both name each jar specifically and then name all entity classes from both jars:
<?xml version="1.0" encoding="UTF-8"?> <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"> <persistence-unit name="puName" transaction-type="JTA"> <provider>oracle.toplink.essentials.PersistenceProvider</provider> <jta-data-source>jdbc/yourDatasourceName</jta> <jar-file>shared-ejb.jar</jar> <jar-file>application-specific-ejb.jar</jar> <class>shared.entity.bean.package.SomeClass</class> <class>shared.entity.bean.package.SomeOtherClass</class> <class>other.ejb.jar.package.SomeClass</class> <class>other.ejb.jar.package.AnotherClass</class> <properties> <property name="some.property" value="true"/> <property name="some.other.property" value="4"/> </properties> </persistence-unit> </persistence>
Everything else remains pretty much the same as it did in my earlier example, and as far as I can tell (… so far, at least!), everything seems to work just fine.
Maybe I’m just getting old and slow, but I don’t remember having this much trouble finding out how to do something for quite some time. It seemed like such a normal, every-day requirement: build an EJB .jar file in such a way that I could configure the datasource reference externally, which would allow me to use these components in multiple applications without having to rebuild the EJB .jar uniquely for each independent use. Surely I was not the first person to have such a need. But after searching and searching, I starting to think that it just could not be done, to which I has the same response as this guy:
ahhh vinnie i feel your pain!
i’ve been looking for a solution to this for so long as well. and the solutions offered are always along the same lines.
i can’t believ an ‘ENTERPRISE’ component platform as JEE is supposed to be is so crumby. i guess they’ve only had six chances over what? ten years to get this right.
the fact that runtime configuration is embedded INSIDE the actual deployables and there is no way to override them is the biggest JEE spec joke.
even worse, when using EAR files, the database is hard coded inside a deployable of the deployable. so in the case above for an ear you’d have to unzip the ear file, possibly unzip every jar file, change one line in a descriptor, rezip everything and then redeploy for every seperate deployment. i have spent countless hours reading the specs trying to find the fix for this – as i simple could not BELIEVE there would be none for such an obvious situation.
and this is how its supposed to be? this is the best we can do? even for third party components supplied by someone else? still? in 2010? really? you’re serious?
hows this for a consumer product brochure – in order to change the channel on your tv, get a phillips head screwdriver and take the back off your remote control, pull apart the board and xxxxx….
Fortunately, though, it really can be done; there are just quite a few things that all have to line up in order for it to actually work. At least I was able to make it work on Glassfish 2.1.1 using a project composed of an .ear file that contained both a .war file and an EJB .jar file. Your mileage may vary, but here’s what I ended up with once I finally got all of the parts to play nice with each other:
.ear file +- /lib directory | +- persistence.jar file | +- /META-INF directory | +- persistence.xml file +- webapp.war file +- ejb.jar file
First of all, you have to remove the persistence.xml file from inside the EJB .jar file. There should be no persistence.xml file in either the ejb .jar file, the webapp .war file, or even loose in the .ear file. The persistence.xml file should be located in the META-INF directory of its own independent persistence.jar file (choose any name that you like for the .jar, actually), which should then be place inside of a /lib directory, which should be placed at the root of the .ear file along side the webapp.war file and the ejb.jar file.
It is also important the that the persistence.xml file name the persistence unit explicitly, name the ejb.jar file explicitly, and itemize all entity bean classes. When it is all said and done, it should look something like this:
<?xml version="1.0" encoding="UTF-8"?> <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"> <persistence-unit name="puName" transaction-type="JTA"> <provider>oracle.toplink.essentials.PersistenceProvider</provider> <jta-data-source>jdbc/yourDatasourceName</jta-data-source> <jar-file>your-ejb.jar</jar-file> <class>your.entity.bean.package.SomeClass</class> <class>your.entity.bean.package.SomeOtherClass</class> <properties> <property name="some.property" value="true"/> <property name="some.other.property" value="4"/> </properties> </persistence-unit> </persistence>
Inside of the .war file, I also placed an ejb reference in the web.xml file, and added an annotation to one of the servlets referencing the persistence unit name. The ejb ref was pretty standard stuff:
<ejb-local-ref> <ejb-ref-name>ServiceName</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <local-home/> <local>your.stateless.service.package.ServiceName</local> </ejb-local-ref>
… as was the servlet annotation:
@EJB(name="ServiceName") @PersistenceContext(unitName="puName") private ServiceName serviceName;
In the EJB annotation, the value of the name parameter must match the value of the ejb-ref-name element in the web.xml. In the PersistenceContext annotation, the value of the unitName parameter must match the value of the name attribute of the persistence-unit element in the persistence.xml file.
That’s it. It took me forever to figure it all out, and some of the things that I have done here may not even be necessary, but once I got it to work, I stopped looking at it and moved on to other things. I just wanted to lay it all out here before I forgot, plus I hate to see someone else have to go through the same thing. Hope this saves someone that trouble!
Seriously? Do things really have to be this complex? It’s not as if getting into the Swing of things is an easy task in and of itself, but then you have to learn to wrap. And then once you get through that, you have to learn to pack. And not just pack, but pack for multiple destinations. It’s enough to make a person want to swear off even thinking about working on a client-side application ever again.
Meanwhile, back on the web, the rule seems to be that once you get familiar with all of the parts and get really, really good at something, that something suddenly becomes a thing that we just don’t do anymore. Really getting the hang of those *.xbm.xml files? That’s nice, but that’s a useless skill now that we’ve moved on to annotations. Developing a special knack with those *.betwixt files? Oh, well … there will never be a need for that again now that we’ve all moved on to JAXB. Finally getting really comfortable with all of the nuances of Hibernate? Never mind — we’re all moving over to EJB3; we don’t even need Hibernate any more. Getting to know Spring like the back of your hand? Who needs that now that we have container-managed dependency injection? And those RESTful Java servlets that you can just crank out in your sleep now that you’ve been doing it for a while? That’s just useless knowledge that you will never need again now that we can do everything and more with Jersey resources.
Experience is just another word for Old School … forget whatever you learned yesterday — today is a whole new world!
At least it seems that way much of the time. But then you have to stop and remember that all of this Java stuff is just fluff anyway. Way back before the days of Java, when these little toy personal computers just started coming out and no one had yet heard the word “Internet” spoken aloud, I was let in on a little tidbit of wisdom that has been lost through the ages, and may not even be comprehensible to many of today’s premier web technologists:
“Real programs all begin with the words IDENTIFICATION DIVISION.”
I guess I have always been a Web programmer, and not a Java programmer. My first “dynamic” web pages were generated on an IBM Mainframe by a COBOL program and then placed on the web server by an FTP step in the JCL. Later on, I discovered the joys of Perl and CGI, and eventually, I found my way to Java (I still can’t get used to the Oracle brand popping up on that link!), once again thanks to IBM and their WebSphere line (and their now ancient history VisualAge for Java IDE).
So, I have been coding Java for a long time, but just that subset of Java that lives within the realm of a web application server. I never really had occasion to build anything like an application with its own GUI that lived on the desktop. For one reason or another, that’s just something that had never come up.
It may be the same language, but I have to say, it’s an entirely different world. Labels and Frames; Panels and Panes; Listeners and Layouts; TrayIcons and Popups; Bindings and Actions; GridBagLayouts, SplitPanes, Buttons, and Borders.
Timers and Workers and Threads … Oh, My!
We are definitely not in Kansas anymore, Toto!
The other day I needed to create a bookmarklet, which was an interesting exercise in and of itself, but once I got all of those issues worked out, I wanted to make it pretty by adding an icon. Apparently, this is not something easily accomplished, and there is little information out there that I could locate on how one might go about doing this. I did manage to find this, though, over at tapper[ware]:
Now, I have to say that his little hack to make all of this magic happen is rather ingenious, and I do like it. I just could not get it to work in my version of Firefox. Everything started out great in the beginning. The first example worked just fine for me. I can take this little icon:
… and add it to this bookmarklet:
Apparently, I’m just not smart enough to figure that out, so I did the next best thing and just gave up trying, and then went with a slightly different approach:
This version uses the
There’s probably a better way to do this still, but I did what I could to do what I wanted to do, and that’s going to have to be good enough for now!
For the longest time now I have been WWWAAAYYY too busy to even think about doing any blogging, but hopefully that is all starting to change now. Things are starting to settle down a little, and I should have a wee bit more time.
Speaking of time (nice segue, no?), I have been having fun with ISO 8601 dates and times for quite a while. On the sever side, I have just been using plain old java.util.Date and java.text.DateFormat. Then I found this:
According to their home page, “Joda-Time has been created to radically change date and time handling in Java. The JDK classes Date and Calendar are very badly designed, have had numerous bugs and have odd performance effects.”. At this point, I have only played around with DateTime, but I have to say that I like it so far.
One thing that I never did like about DateFormat was that the Time Zone component never rendered out with the colon (“:”) in between the offset hours and offset minutes. I had to add this code:
String string = FORMAT.format(date); return string.substring(0, string.length() - 2) + ":" + string.substring(string.length() - 2);
… to this back in the day. With Joda Time, you can accomplish the same thing with this (assuming that “date” is a Joda Time DateTime object):
String string = date.toString();
It’s one of my new standards!