04.17.07
Posted in Uncategorized at 6:26 am by skoobi
Just a few words to give my opinion about this post on Acegi and AppFuse 2.0.
ACEGI
1. If you use composition, your domain objects don’t have to implement the UserDetails interface, so you don’t have to “pollute” them.
1′. Even if you do not use composition, implementing an interface doesn’t mean your domain objects are not POJOs anymore. However, having to inherit some base class makes them not POJO, which is not the case with Acegi.
2. There is no concrete provider, but once again, if you wrap your AccountDao (or whatever JPA/Hibernate Dao ), implementing the provider takes 2 or 3 lines of code….
3. Yes, indeed the documentation is not easy to deal with…
APPFUSE
1. Annotations vs XML debate… I guess it’s a matter of taste.. XML is definitely more powerful, etc, but you don’t generally need this power, and ease of maintenance can be considered as more important that theoretical flexibility…
2. I agree.
Permalink
03.03.07
Posted in Uncategorized at 1:26 am by skoobi
I happened to read this blog entry about NOT reinventing the wheel. I 100% agree with the author. However, I would like to add something important : Reinventing the wheel is bad, but integrating too much stuff together will necessarily cause headaches about version incompatibilities, subtle problems, etc..
For instance… Let’s say you want to display AJAX-pages that will query the server asynchronously for some stuff, and display the result to the user. One of the best alternatives is DWR, so let’s say you use version 2, because it supports annotations, etc..
Now, you want to create AJAX-validation of your forms. You don’t want to reinvent the wheel, so you use something like Struts2, with the ajax theme. Bad luck ! Struts2 seems to work fine with DWR1, but one will have problems with DWR2… How do you solve the issue ? Patching, patching, patching, if you have the time.
The problem is that this kind of headaches constantly happens whenever you use a few frameworks and libraries, which completly kills the productivity… Another real headache would be the use of Spring 2 + AspectJ + Hibernate to Dependency-inject POJOs… The problem + solution is described on this post…
Another example I came accross would be the incompatibility between some prior ActiveMQ version (before 4.x was released) and Spring 2.0, whereas everything was working fine in 2.0 RC4… The problem came from Xbean 2.6 which was incompatible with Spring 2.0 final….
And I could post hundreds of framework-headaches … I am not saying frameworks and libraries are bad (otherwise, I wouldn’t use them), but they’re not paradise either…
Permalink
Posted in Uncategorized at 1:08 am by skoobi
I came accross this blog entry which is a mini “howto install maven2 under debian”. Thanks for the hint, and thanks to the Debian Java team for working on official Debian packages for maven2.
However, I think we have a deeper problem than just the lack of maven2 package.. Just take a look at the number of jars in Maven2 repository. And this doesn’t take into consideration the jars offered on Java.net repository, or Apache Incubating one.
So, what is the problem exactly ? Well, it is going to be IMPOSSIBLE for Debian to keep up with the crazy and constantly increasing amount of Java jars available. So, instead of trying to re-package Java libraries once again (mainstream developers already have to package them for maven1 and maven2), why not work on some integration between Debian Packages and Maven2 ones ? And when you think a bit about it, Debian has the same problem with PHP PEAR and and Perl CPAN.
Maven2 is a full-blown java package system that expresses dependencies, etc. So, to my opinion, what Debian should do is the following :
- Create a notion of a “soft-depencency”. Basically, this would mean that any Package can have hard dependencies (the current deb dependencies), and soft dependencies which could be resolved by a soft-dependency subsystem.
- In order to deal with Java, CPAN and PEAR’s case, a soft-dependency could be expressed as prefix:dependency. A soft-dependency manager could register a prefix, and the dependency string would be subsystem-specific. So, for instance, if I need freemarker, the dependency could be maven2:freemarker/freemarker/2.3.8
Now, the question is whether Debian is ready to accept such a shift in its concept ?
Permalink
01.19.07
Posted in Uncategorized at 12:30 am by skoobi
In a recent post, Ian lists the current limitations of Xen 3.0. Nice work ! Definitely Useful, but I would just like to add that there is a trick that I previously described, to circumvent the 3 network interfaces limit.
Permalink
11.28.06
Posted in Uncategorized, Java at 7:17 am by skoobi
Dalibor Topic has been interviewed (post here) concerning the recent announcement of Sun to make Java GPL, its implication on the Kaffe project.
As far as I am concerned, I strongly believe that Open Sourcing Java will open the door to more innovation and wider adoption around/of this technology. When it comes to high-level languages, the only truly Free (Libre) option on the linux/*NIX desktop was to use Mono/C# (more and more GNOME applications are written in C#). Adding more competition by releasing Java Open source will most probably lead to better, easier to maintain applications.
Another important point about the GPL’ing of Java is that Java itself will benefit from the change. Look at GCJ, for instance, which tries to get rid of the JVM and directly compile java to machine Code. It is yet to prove whether this approach would actually make Java faster, but in any case, it would help to better integrate Java with the unix-way of doing things, instead of having Java on one side, and the whole OS on the other side. Few to no efforts have actually been done in order to mix high-level languages with the system. GCJ is currently struggling to implement both the language and classlib aspects of Java. Once the classlib will be released as Open Source software, GCJ developpers will be able to concentrate on the compiler itself, and on the integration of Java with C/C++ code, which will be an incentive for the people who don’t like JVMs to use Java (after all, Java will just be a simpler C++ that provides a decent library by default).
Permalink
11.04.06
Posted in Uncategorized at 1:25 pm by skoobi
The Can Java CMS match PHP ones article contains a funny, yet sadly true, sentence :
Maybe while the Java world was engaged in talking of high end, super techie stuff, with the words ‘enterprise’, ‘transactions’ and ‘SOA ‘embedded in every sentence, the PHP guys actually went out and created a lot of simple yet very useful software.
And we can also cite the following article : Why I hate frameworks which goes in the same direction, and is pretty funny too 
Permalink
06.18.06
Posted in Uncategorized at 11:39 am by skoobi
Every web application needs to load initial data into its production database (settings and domain specific data such as available categories, etc..).
Another concern is the migration of current data to the new schema. Hibernate/JPA makes it easy to create additional fields, but as soon as data migration is needed, it is necessary to have something more robust.
That is my current concern : I want to create a decent import/migration system.
Requirements :
- Versioning : Launching a migration should detect the current state of the database without breaking things if the data is up to date
- Heterogeneity-friendly : Some data come from XML, others are plain SQL scripts, some are calculated…. So, the importer system should play well with many kinds of sub-importers.
- Transaction-enabled : if an importer crashes, it must leave the data in the previous state
- Developer-friendly and extensible : it should be easy to add new importers for additional sets of data
I am still unsure about how I should do things, so if anyone has already worked on something similar, I am open to ideas.
In any case, once I work out something nice, I’ll re-post
Permalink