I just noticed that it has been 2 years since I posted anything. Ha!
Tuesday, June 12, 2012
Tuesday, June 15, 2010
Spring Criticism, part 2
Ok, I am back with a funky track.
First off, this is not a rant, or a complaint. I just recently hit some functionality within the Spring OSGI container which seems poorly designed, and I wanted to share the love.
So, OSGI is all the rage these days, supposedly. Or so it seems on various marketoblogs disguised as blogs. After a lot of hatin' on/at those blogs, I finally got around to checking it out. Imagine my surprise! OSGI is actually really goddamned awesome. Bundles, dependencies, dynamically bringing them up and down, eeehhh, not so much, but bundles and dependencies! Yayyy. I'm happy.
Enter Spring, with their "I gonna configure your world so hard, you're not gonna know how I configure your world so hard" mentality. After a tiny learning curve, I was happily writing Spring configuration XML files, lusting after the functionality that lay hidden behind various goodies such as spring-osgi-web and spring-osgi-web-extender. I have some experience with the Servlet spec, and it all made sense.
What I wanted to do was deploy a war in an already existing OSGI container, as a bundle. Well, that sounds pretty simple, right? You throw together the webapp, required libraries follow the Servlet spec and reside in the warfile's ${home}/WEB-INF/lib. Throw it in the osgi startup and you're done!
java.lang.ClassNotFoundException
O_o. No! This cannot be! I did everything riiiiiight. Wait a second... The docs say you have to add the jars required by your webapp to the MANIFEST.MF file within ${home}/META-INF. Of course, how could I be so stupid, this is OSGI. Duh!
Or is it a "Duh?" This specifically allows for war files that break the Servlet spec to actually work within an OSGI container's Spring-powered web bundles. Not only can jars be outside of WEB-INF/lib, classes don't have to be within WEB-INF/classes. This is where things kinda get weird. Why would Spring folks (now VMWare, blah blah) want to do this? Why not spend a little extra effort and scan the war file as a J2EE-compliant server would, and make our lives even easier by automatically including the jar files found within to our bundle's classpath?
I don't know. Perhaps they ran out of time. Perhaps no one is using their DM server tech and this has not come up. I do know that this does not quite fit in with their philosophy of "non-invasive configuration." It effectively breaks the Servlet spec.
I am all for that don't get me wrong, technology has to move forward. But why this sudden break with backwards compatibility?
For conspiracy theorists, the other possibility is that Spring is attempting to become the dominant Java enterprise tech puddle that we, the Spring semi-programmers (now with 110% more configuration skills) lurk in.
My two cents? I like the mud here. But I'll be damned if I don't call it out for being mud.
First off, this is not a rant, or a complaint. I just recently hit some functionality within the Spring OSGI container which seems poorly designed, and I wanted to share the love.
So, OSGI is all the rage these days, supposedly. Or so it seems on various marketoblogs disguised as blogs. After a lot of hatin' on/at those blogs, I finally got around to checking it out. Imagine my surprise! OSGI is actually really goddamned awesome. Bundles, dependencies, dynamically bringing them up and down, eeehhh, not so much, but bundles and dependencies! Yayyy. I'm happy.
Enter Spring, with their "I gonna configure your world so hard, you're not gonna know how I configure your world so hard" mentality. After a tiny learning curve, I was happily writing Spring configuration XML files, lusting after the functionality that lay hidden behind various goodies such as spring-osgi-web and spring-osgi-web-extender. I have some experience with the Servlet spec, and it all made sense.
What I wanted to do was deploy a war in an already existing OSGI container, as a bundle. Well, that sounds pretty simple, right? You throw together the webapp, required libraries follow the Servlet spec and reside in the warfile's ${home}/WEB-INF/lib. Throw it in the osgi startup and you're done!
java.lang.ClassNotFoundException
O_o. No! This cannot be! I did everything riiiiiight. Wait a second... The docs say you have to add the jars required by your webapp to the MANIFEST.MF file within ${home}/META-INF. Of course, how could I be so stupid, this is OSGI. Duh!
Or is it a "Duh?" This specifically allows for war files that break the Servlet spec to actually work within an OSGI container's Spring-powered web bundles. Not only can jars be outside of WEB-INF/lib, classes don't have to be within WEB-INF/classes. This is where things kinda get weird. Why would Spring folks (now VMWare, blah blah) want to do this? Why not spend a little extra effort and scan the war file as a J2EE-compliant server would, and make our lives even easier by automatically including the jar files found within to our bundle's classpath?
I don't know. Perhaps they ran out of time. Perhaps no one is using their DM server tech and this has not come up. I do know that this does not quite fit in with their philosophy of "non-invasive configuration." It effectively breaks the Servlet spec.
I am all for that don't get me wrong, technology has to move forward. But why this sudden break with backwards compatibility?
For conspiracy theorists, the other possibility is that Spring is attempting to become the dominant Java enterprise tech puddle that we, the Spring semi-programmers (now with 110% more configuration skills) lurk in.
My two cents? I like the mud here. But I'll be damned if I don't call it out for being mud.
Sunday, February 14, 2010
Damn, Overgrowth
Sup y'all.
I've been away for a bit due to an interesting business trip. Luckily it's now over. I'm not going to name any names, but don't ever go to Monaco expecting Monaco Telecom to provide internet faster than a 56k speeds. Sure, it is citywide wireless... but it is SO SLOW. If anyone ever wants to study the effects of monopoly on the quality of service that telecoms provide, go to Monaco and try to download anything. I got burned, badly.
But the main topic of my post! It is just a link. If you are not yet aware of what these folks are doing, you really ought to check it out. It's the future.
I've been away for a bit due to an interesting business trip. Luckily it's now over. I'm not going to name any names, but don't ever go to Monaco expecting Monaco Telecom to provide internet faster than a 56k speeds. Sure, it is citywide wireless... but it is SO SLOW. If anyone ever wants to study the effects of monopoly on the quality of service that telecoms provide, go to Monaco and try to download anything. I got burned, badly.
But the main topic of my post! It is just a link. If you are not yet aware of what these folks are doing, you really ought to check it out. It's the future.
Tuesday, December 29, 2009
Bwahahahahaha
This made me laugh so hard. I love this man!
http://java.dzone.com/articles/secret-architects-cabal#comment-23121
http://java.dzone.com/articles/secret-architects-cabal#comment-23121
Monday, December 28, 2009
Cygwin 1.7 Installation Problem
So, I was hangin' out at work today. And I decided I wanted to have a C/C++ environment up and running, because it looks like I have some C++ development ahead of me soon.
I downloaded and installed the Netbeans 6.8 C++ environment, in the desire to try something new. It expects either Cygwin or MinGW and is pretty well integrated with Cygwin. So I created my little test project, and tried to compile my main.cpp file, which compiled but on the linking stage, OH GOD THE PAIN.
Yes, friends, pain. See, I had not installed the liblstdc++.a file yet. Well, no problem, I will just run the setup.exe and grab them right? Sort of. Since the version is now 1.7 there is a very fun, evil popup that says
Download incomplete. Try again?
The solution is to hit "yes." This brings you back to the mirror server select screen but the key is, your already downloaded archive files are SAFE AND SOUND. There seems to be some sort of bug with the setup.exe file, but if you keep hitting yes and choosing the same exact mirror server, and then just hitting next on the feature select screen, all is well. The setup will only download the files it has not yet grabbed. As a further note, I had to purge my system of any previous Cygwin files and registry entries in order for the install to work.
I downloaded and installed the Netbeans 6.8 C++ environment, in the desire to try something new. It expects either Cygwin or MinGW and is pretty well integrated with Cygwin. So I created my little test project, and tried to compile my main.cpp file, which compiled but on the linking stage, OH GOD THE PAIN.
Yes, friends, pain. See, I had not installed the liblstdc++.a file yet. Well, no problem, I will just run the setup.exe and grab them right? Sort of. Since the version is now 1.7 there is a very fun, evil popup that says
Download incomplete. Try again?
The solution is to hit "yes." This brings you back to the mirror server select screen but the key is, your already downloaded archive files are SAFE AND SOUND. There seems to be some sort of bug with the setup.exe file, but if you keep hitting yes and choosing the same exact mirror server, and then just hitting next on the feature select screen, all is well. The setup will only download the files it has not yet grabbed. As a further note, I had to purge my system of any previous Cygwin files and registry entries in order for the install to work.
Neat Way of Looking at Patterns
Haven't really finished understanding this entry. But it seems real good!
SPAMSPAMSPAMSPAMSPAM
http://www.ibm.com/developerworks/java/library/j-eaed9/index.html
Aaaah, spam complete.
SPAMSPAMSPAMSPAMSPAM
http://www.ibm.com/developerworks/java/library/j-eaed9/index.html
Aaaah, spam complete.
Monday, October 19, 2009
JSR 317
So, JSR 317.
Very cool, very awesome JSR. What's cool about it? Well you see, it makes a Java standard of a technology I am already intimately familiar with! So it's really really great!!!
Ok, I was being sarcastic. Whether or not ORM is a Good Idea™ is still not completely settled in my mind. There is a relatively large amount of overhead, within the knowledge that programmers must have AND efficiency. Also, everyone is doing it.
The good news is that the overhead is partially addressed with the new stuff in JPA 2.0, specifically the Criteria API. This API goes a long way to completely replace the Database with Objects in the mind of the Java enterprise programmer, leaving a scarred wasteland of smoking JDBC bodies and tormented souls of DBAs. In intervals divisible by 2 those souls cry out with words that chill the very spine of those who hear them. Words like "normalization," "query efficiency" and "this is not a search engine."
Well to be fair those last two were phrases.
Oh well. Anyway, I am looking forward to Nov 16th, when the JSR is supposed to hit the streets. I mark the date with a shot of rakia, a toast to the people that told me I must take Relational Databases in college, or else risk not being ever hired as a programmer.
Very cool, very awesome JSR. What's cool about it? Well you see, it makes a Java standard of a technology I am already intimately familiar with! So it's really really great!!!
Ok, I was being sarcastic. Whether or not ORM is a Good Idea™ is still not completely settled in my mind. There is a relatively large amount of overhead, within the knowledge that programmers must have AND efficiency. Also, everyone is doing it.
The good news is that the overhead is partially addressed with the new stuff in JPA 2.0, specifically the Criteria API. This API goes a long way to completely replace the Database with Objects in the mind of the Java enterprise programmer, leaving a scarred wasteland of smoking JDBC bodies and tormented souls of DBAs. In intervals divisible by 2 those souls cry out with words that chill the very spine of those who hear them. Words like "normalization," "query efficiency" and "this is not a search engine."
Well to be fair those last two were phrases.
Oh well. Anyway, I am looking forward to Nov 16th, when the JSR is supposed to hit the streets. I mark the date with a shot of rakia, a toast to the people that told me I must take Relational Databases in college, or else risk not being ever hired as a programmer.
Subscribe to:
Posts (Atom)
