Infoq posted a nice presentation by Gregor Hohpe, where he talks about SOA. For him domain specific languages could be an answer to over complicated general languages like BPEL.
Also if you havent done so read his article about starbucks and the two phase commit: a very nice analogy about asynchronous communication in a real world example.
Well, who can say he didn’t see this one coming. JBoss development will apparently switch to the Fedora model. That means a community edition will be developed out in the open, and releases will be made on a regular basis with less attention to backward-compatibility. Based on that subscribers will get a more stable “enterprise” version.
Hard to say if this will work out in the application server market. If you want stability and backward-compatibility, you’ll most likely have to opt for the subscription model which is probably fine with companies relying on both.
On the good side this might mean faster integration of new features into the community edition.
The switch is supposed to happen in June. We’ll see how it works out.
Yes, I know, there is this great tool JRuby which will hopefully be an essential
part of the JDK in the near future, and yes there is
REST where Restlet seems to be the most promising framework,
but all I wanted is to speak with a very simple Java Interface from a Rails application.
So I thought there must be an easier way, but it has to deal with ongoing changes to the interface.
The answer for me was the Burlap protocol which you get with Spring for free.
All you have to do is to expose your Java bean with the Burlap exporter:
<bean id="fooService"
class="com.agelion.server.impl.DummyService">
<bean name="/FooService"
class="org.springframework.remoting.caucho.BurlapServiceExporter">
<property name="service" ref="fooService"/>
<property name="serviceInterface"
value="com.agelion.server.FooBackendService"/>
</bean>
. Thats it for the Java side. Burlap is a very simple protocol where you dont map classes, what you get is a map with key, value pairs. But thats fine for me.
But also the Ruby side is easy to implement. I am still a newby with Ruby but that was relativly quick done (though its still not as easy to get information like you get for J2EE for instance, where you get too much information).
Because the Burlap protocol just supports the POST method you need the low level Ruby methods for Http:
Net::HTTP.start('localhost', 8080) do |request|
response = request.post('/backendservice/FooService',
'<burlap:call><method>myMethod</method></burlap:call>')
And here we go. All you have to do is to parse this XML:
vals = []
XPath.each( Document.new(response.body),
"//burlap:reply/list/map/*")
{|p| vals << p.text }
And as I said, what you get are key-value pairs with the exception of the first element which descripes the original type (classname).
I converted it to a map skipping the first element in the array:
@bashvals = {}
1.step(vals.length-1, 2)
{ |i| @bashvals[vals[i]] = vals[i+1] }
Often forgotten because most of the time you want to proove that your code runs. Yes I know we all tend to be lazy. But to be complete in a sense of Sir Carl Popper you also have to falsify your assumption. You are forced to think about deeper about what your code does and what it should not do. But even further you proove that exceptions are treated correct in case of an error or worse like it happened to me it gets swallowed. I was about to refactor an ancient piece of software written in the early days of Java development. I wrote a test for a new feature and was happy to see my test was successfull. But writing a failure test I recognized that every exception was swallowed by an nice try {} catch (Exception) block just because this test failed.
While I like maven2 because of its productivity benefits now a simple task was taking me some time of research. I have to deal with some legacy code where some tests exists, but these are plain java code with main methods. I look forward to refactor them to junit tests, but step by step. So I have to tell maven what class to use and what not. For two reasons I’d like to gather them all in a testsuite. First I could start the suite easily from my IDE, and second I have another testsuite, which will require an external Corbaserver running. So I would like to seperate these tests.
There are two points to consider:
1) Because maven doesnt seem to work with suites you have to write a TestCase like this:
public class SuiteTest extends TestCase {
TestResult tr = null;
public void testSuite() {
TestSuite suite = (TestSuite) YourTestSuite.suite();
suite.run(tr);
}
public void run(TestResult res) {
tr = res;
testSuite();
}
}
2) Whereas in maven1 it was simple to configure the unit tests with the <unittest> tag, this doesnt work in maven2 anymore. In the pom.xml you have to configure the surefire plugin which runs the test. Thats not obvious for a maven1 user, so its not easy to find the right documentation. But the maven2 concept is to be more plugable. So its easier to include Testng for instance.
In a discussion the topic of defaults in transaction demarcation for session beans I made an interesting yet somehow shocking discovery. Someone wanted to tell me that the default would be Supports (which means transactions are supported but aren’t created for the called method if none exists). Since all our session bean methods use access the database and write data this didn’t make sense. So I went through the specification, and to my surprise found not a single mention of the default transaction type to be used by the container in case the assembler forgot to specify it. Nothing on unspecified behaviours in this case either.
So the code worked until now without explicit demarcation, what gives? Seems like the JBoss default is Required (i.e. create a new transaction or use an existing one). While you shouldn’t rely on the default here, I’m rather shocked that it’s not mentioned anywhere. I browsed a few books on EJBs, searched the JBoss website, nothing except these forum posts.
I made sure the deployment descriptor now correctly demarcates the correct transaction type, but that still leaves a foul taste. So make sure you don’t rely on defaults, but declare exactly what you’d like the container to do for you.
Mind you, this changed in EJB 3.0, where Required is the default, in both annotations and the deployment descriptor.
I spent half of the day hunting down a nice issue related to external JavaScript files and a group of `
The block containing the variable declaration never got executed. The reason? Both Firefox and Internet Explorer went straight ahead and parsed the stuff until the ending `` and because of the fact that `
As an experiment I tried declaring the HTML as being XHTML, but even that didn’t help. Or maybe I have been staring at this code for too long.
All those doubts and fears that I’m too stupid for this, they’re all real!
Finally, the second edition of the classic and must-have “Hibernate in Action” finally made it to Manning’s Early Access Program. The first chapters of “Java Persistence with Hibernate” are available now, with more to come. The book will of course also feature EJB3 related information.
Looks like Hibernate finally gets a worthy reference manual. As much documentation as there is, it’s still very under-documented. Hopefully the second edition fills this void even better than the first one.
Too bad. A new project popped up on the horizon, and its most important deadline is September 15th. The choice was either the project (and therefore earning money) or RailsConf Europe in London.
Well, see you next year, or at RailsConf Germany.
Maybe I was too harsh last time or too emotional. Of course this is part of our jobs. From the project view I guess as a startup you can live like this for a while. Especially if you dont have too much code to write, or customers who pay a hell of a lot of money for your product. But if the project comes into the years, some developers passed by, you have some code nobody has an glue about, had some dirty hacks to make without cleaning up afterwards the chaos starts growing and the troubles begin. Then you need some rules.
I have seen too many freelancers who resignated due to these cirumstances in some projects. They say, oh well, its their problem, if I get my money everything is ok. With this nothing gets better. So I started writing a paper, but how to tell them what they dont wanna know?
* Stay positive but certain. Saying things in a positive way helps them to understand you. Tell them what they gain with the changes and not what desaster is going to happen or thats all bullshit what they are doing. Tell them about the increasing motivation, that they are going to be more productive.
* Explain them whats wrong and how it could be solved. Have at least one chapter where you show some starting points. As an example if they dont have any tests, how they could start writing tests, at the best show some examples.
* Stay honest, dont promise things you cannot hold. If all goes well your paper will be an important one. They will take every word very serious.
* Though the managment decides stay connected with the team. Not necessarily with all, but if it comes to changes you need at least some of them.
* Consider the consequences. It happend to me one time that after the CEO read our paper the project leader and team leader had been suspended because their reports draw a wrong picture about the project (and we could proof our statements). So insist its nobodys fault and they have to look ahead and not behind. If personal consequences are not avoidable its at least not your fault. You just told the truth.