We Keep Coding

MVC and Swing in desktop application

After realizing that I have completely ignored the MVC pattern I have tried to utilize the concept in an application with a Swing view. I have now read most of the posts on the subject of MVC with Swing but am still a bit confused, because it is too complicated for me to grasp, and I think I need some basic clarifications so I don't set off on the wrong path.
I also wonder how common it is to use MVC in real projects. Many online tutorials seem to leave out the controller and mix it with the model, while I was confused by XSTL:s business logic capabilities. Why would you want to address a datasource from a JSP view?
These thoughts aside, my proper question is this:
If you have a Swing component, should event listener in that Swing class update the component state through calling (static perhaps?) methods in a POJO controller class, which in turn gets the appropriate business logic from the model, which is made up by POJO class hierarchy and associated persistence?

I've worked as a freelance for a long time and almost 90% of the projects were about Java Swing (Desktop applications). Also a lot of projects involved migration from languages like Visual Fox Pro to Java, it was a pain, because the hard part is not think in the logic which is already done, the hard part is take the code that is a mess and turn it into a good-looking code following the good practices and using design patterns, that's why it is a good idea to make a schema or a map in your mind how you can separate your code following the concepts of Model, View, Controller.
MVC as mentioned helps you to have a good-looking, maintainable and easy to read code, as well as you follow the programming paradigms and good practices.
View: Obviously, the part that interacts with the user (user interface), in case of Swing, your windows, frames, panels and all the code that involves the graphic components you need for your app.
Controller: Involves the core or business logic you stablish for your application, in this "layer" you should include the functionality and the "how my application will achieve the goals?".
Model: Related with the data you manage, for example, your entities and classes that represents the data you want to manage or give maintenance.
Applying MVC is not so hard, but as I mentioned, it could be sometimes a pain when you have to migrate your code from a not-applying-MVC structure to a MVC structured application. It is easier to start coding using MVC.
A way I get used to it is by using maven and separate my application into little "modules", of course, you don't need maven, I just found it useful in that moment, but in any case you can try practicing or get used to MVC by separating your application into little projects, for instance:
Java Project 1: application-data-model (contains all the code related with data management: entities, dtos, beans, daos)
Java Project 2: application-core-controller (contains all the business logic and functionality, you can use a facade pattern here if you want to make your code more "transparent" when you relate with your view)
Java Project 3: application-view-ui (contains all the panels, frames and graphic components)
Working this way helped me (and forced me) to get used to separate my code and keep an eye on what really matters to the project I'm working on. For instance, if I'm on application-data-model I'm focused in data model, I'm not thinking in business logic nor graphic interface.
Long explanation, maybe somebody could do it better, but hope I could have helped you or at least gave you a hand with this.
Best regards.

Firs the URL for basic understanding of MVC
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Now the approach to implement it in Swing applications. Don't get confused with controller functionality with the listeners functionality.
UI controls and listeners attached to them should be defined in your view classes.
On any event, whenever you need to invoke a business logic, then you need to call the controller class. Like fetching some value from the database.
Controller class should talk to your model to fetch the data and manipulate it if required.
Model classes should work on the data.
The idea of using MVC is to reduce redundant code and more manageable code. So if you are doing some calculations/manipulations then those can be moved to Controllers. Controllers can be called from different views requiring the same stuff. Similarly model can be used by multiple controllers to fetch the data.

Scala, Spring and ActiveRecord with decoupled persistence

I've been doing some reading lately and one thing that I've come across was this article about the Anaemic Domain Model from Martin Fowler. I know, it's old, but somehow very actual in Java world. So I'm trying to move towards a more domain-driven design. One option would be to go with the Active Record model. However, I don't really like the current implementation it has in Scala. It completely couples the domain objects with the persistence type (not so bad in most cases but I have a project where I need to store something both in a RDB and in Mongo). Then I ran across this article about Spring, Hibernate and Scala and though here too the domain object is coupled with the JPA trait, I noticed how he uses Spring to inject a Notification Service. Can't the same mechanism be used to inject a transparent DAO interface? Have you seen this used anywhere? Any thoughts on the idea?

You should have a look at Spring-Data, this project provides some kind of abstraction over different data storages.

How should I design a plugin system in a layered Java EE Application?

I have a Java EE based REST api application. It has a layered architecture like the following:
Resources (Jax-rs resources)
Object Validation
Object Mapper
Service Layer
Repository Layer
JPA Entities
Everything is wired using Spring dependency injection.
I need to design this core application in such a way that it allows other external developers to write extensions/plugins and override or extends any minor or major functionality in the core. Think of it like Wordpress CMS in Java EE if that helps. How would you design a plugin system around the current architecture?
One obvious way that I can think of is override or add new functionality to the proper resource (with validation, objectmapper), service, repository and entity and create a jar + xml out of it. But I want to make sure that the plugin developer has to write the absolutely minimum amount of code to get the new functionality working, while reusing mush of the core code.
Assume, you want to create a wordpress blog post extension that lets you create blog posts with few extra fields that don't exist in core yet. What would be the simplest and cleanest way to go about designing the current Java EE app, so its easy for the plugin/extension developers? Any patterns that could be useful like strategy or template method pattern?
Are there any open source Java CMS that follow the model using Spring/JPA and standard technologies?

I think you mean to extend the functionality, rather than override the core. Typical architecture examples define concerns which can be overridden (separate from core) and make provisions. Eclipse framework achieves this using a combination of plugin-extensions & extension-points mechanism. This is taken further using OSGI bundling.
Another alternative is to breakdown the application into smaller independent modules/services. All you need to do is host these modules over an ESB/Application Integrator (like Mule/Spring Integration) and allow users to configure their version of routing/transformation. Extension would mean creation of new transformers which get added to the message flow.

Looking for design patterns to isolate framework layers from each other

I'm wondering if anyone has any experience in "isolating" framework objects from each other (Spring, Hibernate, Struts). I'm beginning to see design "problems" where an object from one framework gets used in another object from a different framework. My fear is we're creating tightly coupled objects.
For instance, I have an application where we have a DynaActionForm with several attributes...one of which is a POJO generated by the Hibernate Tools. This POJO gets used everywhere...the JSP populates data to it, the Struts Action sends it down to a Service Layer, the DAO will persist it...ack!
Now, imagine that someone decides to do a little refactoring on that POJO...so that means the JSP, Action, Service, DAO all needs to be updated...which is kind of painful...There has got to be a better way?!
There's a book called Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition)...is this worth a look? I don't believe it touches on any specific frameworks, but it looks like it might give some insight on how to properly layer the application...
Thanks!

For instance, I have an application where we have a DynaActionForm with several attributes...one of which is a POJO generated by the Hibernate Tools. This POJO gets used everywhere...the JSP populates data to it, the Struts Action sends it down to a Service Layer, the DAO will persist it...ack!
To me, there is nothing wrong with having Domain Objects as a "transveral" layer in a web application (after all, you want their state to go from the database to the UI and I don't see the need to map them into intermediate structures):
Now, imagine that someone decides to do a little refactoring on that POJO...so that means the JSP, Action, Service, DAO all needs to be updated...which is kind of painful...There has got to be a better way?!
Sure, you could read "Beans" from the database at the DAO layer level, map them into "Domain Objects" at the service layer and map the Domain Objects into "Value Objects" for the presentation layer and you would have very low coupling. But then you'll realize that:
Adding a column in a database usually means adding some information on the view and vice-versa.
Duplication of objects and mappings are extremely painful to do and to maintain.
And you'll forget this idea.
There's a book called Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition)...is this worth a look? I don't believe it touches on any specific frameworks, but it looks like it might give some insight on how to properly layer the application...
This book was a "showcase" of how to implement (over engineered) applications using the whole J2EE stack (with EJB 2.x) and has somehow always been considered as too complicated (too much patterns). On top of that, it is today clearly outdated. So it is interesting but must be taken with a giant grain of salt.
In other words, I wouldn't recommend that book (at least certainly not as state of the art). Instead, have a look at Real World Java EE Patterns - Rethinking Best Practices (see Chapter 3 - Mapping of the Core J2EE patterns into Java EE) and/or the Spring literature if you are not using Java EE.

First, avoid Struts 1. Having to extend a framework class (like DynaActionForm) is one of the reasons this framework is no longer a good choice.
You don't use spring classes in the usual scenarios. Spring is non-invasive - it just wires your objects. You depend on it only if using some interfaces like ApplicationContextAware, or if you are using the hibernate or jdbc extensions. Using these extensions together with hibernate/jdbc completely fine and it is not an undesired coupling.
Update: If you are forced to work with Struts 1 (honestly, try negotiating for Struts 2, Struts 1 is obsolete!), the usual way to go was to create a copy of the Form class, that contained the exact same fields, but did not extend the framework class. There would be a factory method that takes the form class and returns the simple POJO. This is duplication of code, but I've seen it in practice and is not that bad (compared to the use of Struts 1 :) )

I think your problem is not so big as it seems.
Let's imagine, what can you really change in your POJO:
1) name of its class: any IDE with refactoring support will automatically make all necessary changes for you
2) add some field/method: it almost always means adding new functionality what is always should be done manually and carefully. It usually cause to some changes in your service layer, very seldom in DAO, and usually in your view (jsp).
3) change methods implementation: with good design this should cause any changes in other classes.
That's all, imho.
Make a decision about technology for implementing busyness-logic (EJB or Spring) and use its facilities of dependency injection. Using DI will make different parts of your program communicate to each other through interfaces. It should be enough for reaching necessary (small enough) level of coupling.

It's always nice to keep things clear if you can and separate the layers etc. But don't go overboard. I've seen systems where the developers were so intent on strictly adhering to their adopted patterns and practices that they ended up with a system worse than the imaginary one they were trying to avoid.
The art of good design is understanding the good practices and patterns, knowing when and how to apply them, but also knowing when it's appropriate to break or ignore them.
So take a good look at how you can achieve what you are after, read up on the patterns. Then do a trial on a separate proof of concept or a small part of your system to see your ideas in practice. My experience is that only once you actually put some code in place, do you really see the pros and cons of the idea. Once you have done that, you will be able to make an informed decision about what you will or will not introduce.
Finally, it's possible to build a system which does handle all the issues you are concerned about, but be pragmatic - is each goal you are attempting to reach worth the extra code and APIs you will have to introduce to reach it.

I'd say that Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition) addresses EJB 2.0 concerns, some of which would be considered anti-patterns today. Knowledge is never wasted, but I wouldn't make this my first choice.
The problem is that it's impossible to decouple all the layers. Refactoring the POJO means modifying the problem you're solving, so all the layers DO have to be modified. There's no way around that.
Pure decoupling of layers that have no knowledge of each other requires a lot of duplication, translation, and mapping to occur. Don't fall for the idea that loose coupling means this work goes away.
One thing you can do is have a service layer that's expressed in terms of XML requests and responses. It forces you to map the XML to objects on the service side, but it does decouple the UI from the rest.

What are recommendable data modeling tools and techniques for a Flex / Java web app?

I'm looking for a comprehensive setup that you've successfully used already. I've already loads of hints as to what building bricks I might use, but I'm not sure how to put it all together. Tools that need to be bought are OK, too.
Details:
I'm developing a Flex front end client for a Java server application and I have a set of model classes that represent objects in my business logic and should have the same properties and exhibit the same behaviour throughout all layers. These objects
have form validation logic for user input
are displayed in various forms (lists, detail views ...) throughout the UI
are retrieved from and sent to the server using XML or AMF
are validated again on the server
are stored in a RDBM with tables and fields corresponding to the classes and fields
This is a very common application structure, I guess. I'm already using:
ORM for the Java backend (Eclipse persistency package)
automatic mapping from XML to Action Script, using XML schema and the classes in mx.rpc.xml, as described here.
Now, what I'd really like to do is define the objects once (I already have them in XSD) and have tools set up class stubs for the whole chain. What can I use?
I've already heard of (but not evaluated):
XMLBeans to generate Java classes from XML Schema
Granite DS to generate AS classes from Java classes

I don't think your Flex UI should know or care about Java objects.
Take a "contract first", XML schema-drive approach and come up with the messages that you need to exchange between the Flex client and your service tier. Once you have that in place, the two are completely decoupled. That's a good start.
I'd also recommend not buying into a generation scheme. You'll only have to pay that price once during development.
I'm a Spring user, so I'd recommend Spring's "contract first" web services, using the Spring OXM interfaces. That will keep your UI and service tiers nicely decoupled. Use the org.springframework.oxm interfaces to do your mappings.
You can use Spring/BlazeDS to integrate your Flex UI with the Spring back end.
You have the full power of Spring IoC and AOP to create the back end.
I think you'll find it's a good approach for this problem.