incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <>
Subject Re: WikiPage constructors
Date Sat, 13 Dec 2008 12:18:29 GMT

All and none.

The move to JCR means that your old database and JDBCProvider won't  
work anymore.  You will need to migrate to a new DB (and it's still a  
bit early to say how exactly this is going to be done - JDBCProvider  
is not a core component, so someone needs to figure out a way to do  
the migration.)

However, this particular change that is mentioned below has no impact  


On Dec 11, 2008, at 03:03 , Terry Steichen wrote:

> Janne,
> What will be the impact on those of us that use JDBC-based pages?
> Terry
> On Thu, 2008-12-11 at 00:55 +0200, Janne Jalkanen wrote:
>> Folks,
>> there is a minor problem with WikiPages and JCR.
>> In the old days, the recommended pattern was to create a WikiPage
>> with new WikiPage(WikiEngine,String).  The problem is that with JCR,
>> this simply won't be possible, since the WikiPage ceases to be a
>> passive retainer of information, and will actually store a reference
>> to the JCR Node.  This has a couple of impacts:
>> * WikiPages can no longer be cached (which wasn't a smart thing to do
>> previously either, though some internal components did so, mostly to
>> avoid hitting the repository.  Which won't of course be a problem in
>> the future.)
>> * WikiPages cannot be directly constructed anymore - instead,
>> WikiPages will need to be fetched using WikiEngine.getPage() or
>> created with WikiEngine.createPage().  Otherwise, the JCR Node
>> reference would be null, and there would be a bunch of NPEs flying
>> around the code.
>> * WikiPages will not be thread-safe (though no guarantees were given
>> previously either - they just happened to be)
>> [In fact, that's exactly what it does right now, if you check my
>> latest commits to the jcr branch.  We have used the new WikiPage() -
>> idiom pretty liberally everywhere, and that is currently causing some
>> pain.]
>> Now, this change would not be without its merits - it would allow
>> WikiPage to become an interface, and that is very nice (and almost
>> mandatory) if we consider the fact that we would like to have a
>> stable API.  Also, any trick I can think of around this problem
>> either involves overloading WikiContext more, or creating a labyrinth
>> of if( getNode() == null ) setNode( m_engine.getContentManager
>> ().getSession(m_engine.getWikiContextFactory().newViewContext
>> (null,null,this)).getRootNode().getNode(getName())) -calls in most of
>> the WikiPage methods.  Which could be somewhat slow, and would also
>> create two WikiContexts for each request...
>> How do the fellow developers feel about this change?  Does this pose
>> insurmountable problems for anyone, or change any plans?
>> /Janne

View raw message