Waffle is moving from SourceForge to Codehaus. Additionally, and more importantly Waffle and VRaptor teams have decided to join forces.
The Waffle web framework will provide the core architecture for this joint effort. As the first step we have has begun porting Waffle to Codehaus (renaming it to use org.codehaus.waffle package instead of com.thoughtworks.waffle). Next we will begin to gradually port features from VRaptor. The vision of this effort is to create a larger and more consolidated community around a lean web application framework which honours the least-common-denominator principle.
6 comments:
hello mike,
on the new page(http://waffle.codehaus.org/), the download section is empty.
I could find this one:
http://snapshots.repository.codehaus.org/org/codehaus/waffle/
but what would be really interesting to see is a version with source and dependency jars.
thanks, peter
Peter - currently the Waffle team is working towards a 1.0. This release will account for extended functionality and documentation. The core functionality and architecture of Waffle will not be altered. This realease will differ from the 1.0 we have posted on the old sourceforge site because it incorporates some bits from VRaptor project (taglibs).
We do plan on providing downloads which include source and example applications.
The code checked into svn does have an examples module that provides several different examples of using waffle (i.e. simple, paranamer, freemarker).
The only dependency jars a waffle application requires are:
- waffle itself
- ognl
- picocontainer
-- Mike
hi mike,
actually, i think servlet-api is also required (we eventually could build from the new tree ).
also, was there any reason why you did not like my patches regarding fixing the tomcat start up thing and adding setterinjection?
1) waffle prints an error message if sessionContextContainer does not exist in PicoContextContainerFactory's buildRequestLevelContainer method
your solution is to add a hack to tomcat config to solve this issue however this is very inconvenient because many times people just like to drop in a war file or do not have access to the context file (or just do not want to maintain one for waffle). I think this is a much better solution:
if (sessionContextContainer == null) {
sessionContextContainer = (PicoContextContainer) buildSessionLevelContainer() ;
sessionContextContainer.registerComponentInstance(session);
session.setAttribute (Constants.SESSION_CONTAINER_KEY, sessionContextContainer);
sessionContextContainer.start();
}
2) adding this to PicoRegister (and to the abstract class and interface):
public void registerWithSetterInjection(Object key, Class clazz, Object ... parameters) {
SynchronizedComponentAdapter componentAdapter;
if (parameters.length == 0) {
componentAdapter = new SynchronizedComponentAdapter(new CachingComponentAdapter(new SetterInjectionComponentAdapter(key, clazz,null)));
} else {
componentAdapter = new SynchronizedComponentAdapter(new CachingComponentAdapter(new SetterInjectionComponentAdapter(key, clazz, picoParameters(parameters))));
}
picoContainer.registerComponent(componentAdapter);
}
would provide setter injection, your solution about adding a pico instance to the registrar defeats the purpose of the abstract class.
(yes, I also prefer CI over SI but sometimes you have to deal with legacy code)
Would that be possible to add these to features? (At the moment we have to add them manually every single time there is a release)
Please let me know what you think.
...oh and i think jruby is also a dependency
The servlet-api is not required because the web container your waffle application runs in will provide this already. I think the maven war target is accidently including that file at the moment.
The code submission you submitted got lost in my inbox. I'll add this submission to JIRA on codehaus.
The JRuby jar is not required and will only be necessary if you plan on taking advantage of Waffle/JRuby integration, which is still a work in progress look for a new blog entry on this soon
Post a Comment