concept for future magnolia (possibly 3.5) (MAGNOLIA-587)

[MAGNOLIA-608] Spring integration? Created: 09/Dec/05  Updated: 03/Dec/13  Resolved: 03/Dec/13

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: Philipp Bärfuss Assignee: Unassigned
Resolution: Outdated Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MAGNOLIA-2352 OSGi for a module container? Closed
Template:
Date of First Response:

 Description   

From time to time the community motivated us to use Spring framework as the base of magnolia.



 Comments   
Comment by Philipp Bracher [ 09/Dec/05 ]

After introducing the FactoryUtil (commons discovery) and the MgnlContext (neutral application context) I think we can wait for this migration. With this new approach we can make magnolia adaptable very easely. All the major classes like Cache, ... should work this way and allow a custom implementation.

  • we use intrefaces where ever possible
  • no static methods

The implementing class is defined in the magnolia.properties.

MgnlContext allows more neutral interfaces without passing the servlet objects all the time. Different implementation of the context are possible (workflow, ...).

Not using Spring gives us more flexibility and does not cost us a lot. Since we will use DWR and Wicket we could not benefit enough.

Comment by Philipp Bracher [ 12/Jan/06 ]

After looking at the PicoContainer and Spring itself, we decided to use spring core to use IOC (and as a side effect to get AOP too). We will not use other parts like spring MVC (very cool, but we need a control oriented framework like JSF)

Main candidates for getting a spring bean:

  • Cache
  • Activation Mechanism
  • User, Role Management
  • MgnlContext
  • Dialogs
  • Tree

We will introduce it stepwise

Comment by Oliver Lietz [ 12/Jan/06 ]

Good to hear about Spring. If you don't want to use Spring MVC what's about Tapestry and Tacos (components and AJAX for Tapestry)? Tapestry integrates well with Spring. Spring is also a good choice because it's easy to connect Flash/Flex clients (eg with OpenAMF) to the business layer.

http://jakarta.apache.org/tapestry/
http://tacos.sourceforge.net/
http://tacos.mine.nu/tacos-demo4/

Comment by Alexandru Popescu [ 12/Jan/06 ]

The web approach has been discussed longly (I guess you can find something under MAGNOLIA-588). I see no benefit in working with Tapestry. It is neither a standard, not a simple framework. We've been looking around for different solutions, considering 2 aspects mainly: either simple and extensible, or standard.

./alex

.w( the_mindstorm )p.

Comment by Ramon Buckland [ 16/Jan/06 ]

Excellent decision guys. We have been thoroughly impressed with Spring up to now.
It has definitely made our life easier.

Good job!

Comment by Oliver Lietz [ 08/Feb/07 ]

Instead of using the classic Spring Framework/IoC/DI features I suggest to evaluate Spring OSGi http://www.springframework.org/osgi or OSGi http://www.osgi.org/ in general. Magnolia is more a framework than an application. Here are some points why not Spring for frameworks: http://tapestry.apache.org/tapestry5/tapestry-ioc/index.html. The modularization capabilities of OSGi would be quite useful for Magnolia's modules.

http://en.wikipedia.org/wiki/OSGi

Comment by Philipp Bärfuss [ 03/Dec/13 ]

Today we have perfect spring support by the blossom module.

Generated at Mon Feb 12 03:19:07 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.