Screaming Penguin

The aggregator follows some pretty clear design patterns, but I know from trying to figure out other projects that looking at the package names it can be a little tough to figure out what is going on. Basically, it works like this: There is com.totsp.aggregator.model that contains all the POJO classes for the datamodel and spells out how they should work. These are extended elsewhere, but for the sake of complexity management, pretend these are what you are working with. These are brokered by the com.totsp.aggregator.service package. Each coarse grained object has a service manager and a factory. The factory loads its class mapping from the aggregator.properties file. One thing that will be kind of unclear is the separation between the User service and and Content service. The user service just loads the information related to a user from the database: what clusters they have, what feeds are in the cluster. This is loaded from the service.castor.* package. You will also find there are some hacks in the service.castor.model pacakge. This is because there is some really weird shit with castor and doing non-transaction managed Many-to-Many relationships, so I had to do some strange wrapper classes to make this happen. You can really ignore it if you aren't going to manipulate the Data Model. The Content service in service.rome.* is what goes to the Cache and populates the Feeds with entries. This only happens once every 5 minutes min for a user. Since the "Feed" object are managed in the castor database, however, their is only one instance of each one in the system, so an update from cache for one user affects all logged in users using the same feed -- an handy side effect of using castor :) So to render a user, first you fetch the user, then you pass it to the Content service for population before it is rendered. The aggregator.web package contains all the Struts actions and the aggregator.web.forms package contains the struts forms. Yes, I like using the hand built form beans because it clearly delineates what is going on better than the DynaActionForm. The Castor JDO config, AggregatorMessages.properties (Struts i18n) and aggregator.properties (services config) are located in the /src folder of the aggregator project (web) not the aggregator-lib. This was done on purpose, so that when you deploy you can go in and edit the config files without futzing with the jar file. You might, however, want to copies these into the /src/ folder of your aggregator-lib project so you can run localized tests and such without starting a tomcat. Just don't put them in CVS like that. JavaDoc and license tagging in the aggregator project is for crap right now. Once I get the search stuff nailed down a little, I will go in and clean that stuff up. I am going to see about putting it all into the sf.net JWPortal project this afternoon.