Jucas is currently in alpha status.
Jucas is object- (component-) orientated: You may think of Jucas as a form of Struts where the ActionForm-Beans (DataObjects) also contain the controller code. This way the first principle of object-orientated programming ? keeping data and logic together ? can be fulfilled. Where in Struts there are globally named Actions and global shared ActionForm-Beans (DataObjects) in Jucas there are named Components which can be retrieved from a Component-Manager (like in EJB but much simpler) and which encapsulate their own state even in the request and session scopes.
No control code in JSP or other templates for the View (MVC): Like in Struts when an Http-Request comes in the parameters of the request are set directly on the defined Components. The Components than do the request-processing and adapt the model independent of the view.
Both centralized and decentralized event based control: Jucas supports both forms of control. Like in Struts all request processing goes through a central point (the JucasFilter). Here the centralized control can be hooked in. The central controller gets the component from the Component-Manager and like in Struts sets the request-parameters on the component. Because the components hold their own state and control logic - contrary to Struts - they can also have JavaBeans style event-listeners registered and fire events. This way OO-Techniques especially composition and delegation are possible and recommended.
Model-View-Controller (MVC) pattern and agnostic about the view technology: Like Struts the core of Jucas only cares about the Controller and the Model part which can than be rendered by any view technology. However Components may but they don't have to paint themselves.
Pull MVC - Controller is Model II and View is Model I: As stated control and model are separated in Jucas from the view like in Model II. However because the view-designer can plug components together like legos the Model I pattern (where a View uses different JavaBeans) is more flexible for the view-designer than Model II. Jucas supports Model I for the View. This is accomplished by using a Component-Manager through which one, more or even all components in the Web-app can be retrieved and than used (ie model access, form input etc) by each view as needed. The framework takes care that the request handling is split up between the used components, without interfering with the view. This way the component is not a frame(-work) (I call you) but a service to the views (use me). While the advantages of the separation of Model, View and Controller are maintained, the designer gets the lead back - like it should be in the UI-Layer.