Apparently, it has nothing to do with the source folder you see in the Project Explorer view, or the export settings in the Buildpath dialogs: instead you need to edit the Eclipse settings file “project-war\.settings\org.eclipse.wst.common.component” (viewable in the Navigator view) and modify the deployed source folders in there. Changes there do *not* reflect in the Project explorer (at least not with my version of Eclipse, Galileo). I’ve removed the test sourcefolder from there and everything was honky dory.

<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
  <wb-module deploy-name="foo-war">
    <wb-resource deploy-path="/" source-path="/src/main/webapp"/>
    <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
    <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/resources"/>
    <property name="context-root" value="foo"/>
    <property name="java-output-path"/>
  </wb-module>
</project-modules>

trackback

• download PagedList

Lazy loading with the PagedList

Originally I made the PagedList because I needed paged data fetching using JMS queues for a JSF Rich datatable and datascroller; a common problem in JSF but less commonly solved, even less documented and less still solved in an elegant way. Most people are able to solve this problem by using an OpenSessionInView antipattern (keeping Hibernate-oid session open until the view requests the lazy loaded data) but since I’m using JMS queue, this was not an option. I decided to circumvent the entire JSF to JMS queue integration by providing my data in a paging lazy list. It works beautifully.

public class PagedList<Dto, QueryParameters> extends AbstractList<Dto> {

    private final QueryParameters queryParameters;

    private final PagedDataProvider<Dto, QueryParameters> pagedDataProvider;

    private final Map<Integer, List<Dto>> fetchedPages;

    private final int dataSize;

    private final int pageSize;

    public PagedList(PagedDataProvider<Dto, QueryParameters> pagedDataProvider, QueryParameters queryParameters) {
        this.pagedDataProvider = pagedDataProvider;
        this.queryParameters = queryParameters;
        fetchedPages = new HashMap<Integer, List<Dto>>();
        dataSize = pagedDataProvider.getDataSize();
        pageSize = pagedDataProvider.getPageSize();
    }

    public Dto get(int index) {
        int pageNr = (int) Math.floor(index / pageSize);
        if (fetchedPages.get(pageNr) == null) {
            fetchedPages.put(pageNr, pagedDataProvider.provide(pageNr, queryParameters));
        }
        return fetchedPages.get(pageNr).get(index % pageSize);
    }

    public int size() {
        return dataSize;
    }
}

It is different from Apache’s LazyList (and many other implementations) in that it relies on an external dataprovider to provide the dataset’s total size, pagesize and data provision itself. For example, using my lazy list version the size() method actually returns the total size of data potentially available, not just physically available in the list at the present. This way the list works completely transparent to its users. Also, there is no simple factory being passed in that creates dummy objects or something: actual remote data is being fecthed in pages by a data provider. Pages being fetched are independent of each other; when requesting page 5, page 1 through 4 are not need or fetched.

The PagedList works in combo with a PagedDataProvider interface that external dataproviders (some dao for example) could implement. So it has no dependencies whatsoever on some specific implementation. The paged data provider provides the total size of the dataset, the page size and pages of the dataset itself when needed.

Example implementation for JSF and JPA dao

Here’s an example implementation which ties a JSF Richfaces datatable to a JPA dao using a PagedList. I cut out the service layer, view handlers/controllers and whatnot for sake of simplicity.

<rich:dataTable id="searchResults" value="#{appleService.apples}" var="apple">
...
</rich:dataTable>

/**
 * JPA dao which acts as paged data provider for the paged list.
 *
 * Relies on two JPA named queries specified on the Entity being fetched.
 *
 * @author Benny Bottema
 * @see PagedDataProvider
 */
public class AppleJPADao implements AppleDao, PagedDataProvider<AppleDto, AppleQueryParameters> {

    // entitymanager stuff omitted for example (real world: injected by Spring)

    private static final int PAGESIZE = 50;

    /**
     * @see AppleDao#getAllApples(String, String)
     */
    public List<AppleDto> getAllApples(String type, String quality) {
        // optional query parameters: can be null
        AppleQueryParameters params = new AppleQueryParameters();
        params.setAppleType(type);
        params.setAppleQuality(quality);
        return new PagedList<AppleDto, AppleQueryParameters>(this, params);
    }

    /**
     * @see PagedDataProvider#provide(int, Object)
     */
    public List<AppleDto> provide(int page, AppleQueryParameters queryCriteria) {
        Query query = entityManager.createNamedQuery("Apple.findAll");
        query.setParameter("appleType", queryCriteria.getAppleType());
        query.setParameter("appleQuality", queryCriteria.getAppleQuality());
        // JPA's paging mechanism
        query.setFirstResult(PAGESIZE * page);
        query.setMaxResults(PAGESIZE);
        return (List<AppleDto>) query.getResultList();
    }

    /**
     * @see PagedDataProvider#getDataSize()
     */
    public int getDataSize() {
        Query countQuery = entityManager.createNamedQuery("Apple.count");
        return ((Long) countQuery.getSingleResult()).intValue();
    }

    /**
     * @see PagedDataProvider#provide()
     */
    public int getPageSize() {
        return PAGESIZE;
    }
}

Known issues

So far there is only one known issue, which is more of a problem with lazy loading in general: synchronizing the lazy loading list with the remote dataset to avoid becoming stale when changes happen to the dataset. Example: when the dataset changes, the size of the list is not being updated and the get() method may try to fetch wrong or even unavailable data throwing an exception. Since I’m using the paged list in a limited way, I’ve not yet encountered this problem.

One way would be to solve this problem for the Rich datable and datascroller specifically is to have a a4j poll component that listens for dataset changes on the server and refreshes the entire datatable as necessary. Just thinking out loud here…

trackback

www.objectmentor.com/publications/granularity.pdf

My summary of his article (as I understood all of it):

<summary>

• Packages should have a one-way dependency graph. A cyclic dependency leads to having to import code from other packages you don’t always have to use. If an error is made in one of those packages, your code breaks. This can be avoided by removing all cyclic references; in the article he states two interesting solutions (of which one is applying the dependency inversion principle, which is commonly used with classes regardless of any package).
• Packages are release-units. With version control, you can work on a package level that way. Developers or teams are distributed to work on the packages rather than distributed classes. This is also an important reason why not to have cyclic dependencies in packages.According to The Reuse/Release Equivalence Principle Packages are only allowed to (re)use released packages. This is again conform version control principle. This way developers/teams can decide for themselves when they are ready to use a new release knowing it won’t change after they started using it.
• The Common Reuse Principle states that classes that are likely to be used together should be packaged together. An example Robert mentions is a “container and its iterators”. These classes are reused together because they are so tightly coupled and therefore should be packaged together. Again, this seem to be in favor of the version control principle of to affect other packages as least as possible.
• Classes should be packed together according to the The Common Closure Principle. Which states that classes that are likely to change at the same time because of their high dependency-rate should be packaged together.
  Note:
  In OOP there is a class-level principle called the The Open Closed Principle, which states that classes should be closed to change but open to extension. This advocates that you should design a class in such a way that you can change its behavior by extending it rather than editing the source itself. The Common Closure Principle makes sure that when you ever do need to edit a class, any other class that is likely to be changed according to that should be packaged together. Again, this is to improve on package-level version control where you want to minimize the effect on other packages when changing a class in a package.

Also, Robert mentions packages are designed bottom up, meaning you can’t know or approximate packages forehand; packages are *not* indicative of responsibilities or relationships within an application, which is why you can’t design them forehand. They are a building ‘map’ as he calls it to map out how classes should be grouped together in such a way that changes within packages have minimum impact on other packages. Indeed the UML modeling language gives no more information about packages than that (as of UML 0.9, but I don’t think this changed since). This also means packages grow as classes are added. ‘If you do try to design a package diagram forehand without knowledge about the classes, you will likely fail’ as Robert states and end up in badly maintainable classes, lots of “morning after syndromes” and cyclic dependencies.

</summary>

General impression

I had never thought of packages in such a ‘considerate’ way, but it mostly makes sense to me. I guess that’s because some of these things go natural and you do them without rationalizing everything. People generally seem to design packages pretty neatly (in small applications at least) and I think that’s because there’s an intuitive side to it; You just smack together the classes that you somehow feel belong together. That’s why the Common Reuse Principle is probably the most widely used principle, because people subconsciously realize that classes that seem to ‘belong together in a class’ often are classes that adhere to this principle: they are likely to affect each other when changing them.

All in all I think this view rings true, which is confirmed by the fact that you can ‘design’ a package layout in UML. Robert says if you try to design a package without knowledge about the classes, you’ll fail. Obviously if you design an application you get some understanding of its structure and therefor knowledge of the classes. In UML I imagine you do the package diagram just after you did the class diagram, without having to do a bit of coding at all.

There are many guidelines and motivations ofcourse as to how and why package things a certain way, but Robert seems to be on the right track when considering large scale applications, and then desktop applications more so. If you take his advice as a guideline, you could do worse so to speak.

 Slashdot It!   /   trackback