Re: Prevayler Example on Home Page does not Compile

Paul Bennett <[email protected]> Fri, 31 May 2013 11:45:57 -0400
Newsgroups gmane.comp.java.prevayler
Message-ID <[email protected]>
+1 for that. We are currently using version 2.3, where those methods ARE protected, and I've used exactly that technique, to advantage. I see that in 2.6 these have been made private - I'd vote for them returning to protected

-pb

On May 27, 2013, at 6:24 PM, Naveen Chawla wrote:

> Karl are you sure? I'm using protostuff for my transaction serializer, and protostuff-heap (a version of protostuff I made which uses the heap instead of the call stack) for my snapshot serializer, at the moment (I implemented serializer for each).
> 
> I'm not sure I like having another layer.
> 
> I wouldn't mind PrevaylerFactory itself simply having protected methods you could override, such as "journalSerializer()", "snapshotSerializer()" etc. (which just return the default values if you don't override them) as a replacement for all the "configure..." methods. That way, you can create heirarchical, custom PrevaylerFactories (anonymously or named) just by overriding. The existing "configure..." methods could be deprecated but left there for older code to compile & work.
> 
> The xstream dependency could be moved into a separate package with a convenience "XStreamPrevaylerFactory" included (which extends PrevaylerFactory and either calls "configure..." methods in the constructor (if not deprecated), or just overrides "journalSerializer()", "snapshotSerializer", "journalSuffix()" and "snapshotSuffix()" as described above).
> 
> Otherwise I think the base/default factory itself is a core thing.
> 
> (On a side note, since a PrevaylerFactory can't function without a user-specified prevalentSystem, either 1. its no-args constructor should be deprecated, or 2. PrevaylerFactory should be an abstract class for which you must override "prevalentSystem()".)
> 
> 
> On 27 May 2013 15:14, Karl Wettin <[email protected]> wrote:
> I know, and I honestly haven't thought it through clearly yet. Perhaps the factory needs to be rewritten from scratch.
> 
> All I know for a fact is that I always end up cloning PrevaylerFactory and remove almost everything in there in order to get one that has no dependencies except for the serialization I use (which more or less always is java.io.Serializable).
> 
> My gut tells me that the factory should accept a JournalSerializationStrategy, a SnapshotSerializationStrategy and produce a Prevaler, nothing else. Configuration should to be located in the serialization strategy and not in the factory, don't want the factory tainted with settings that makes no sense in some scopes.
> 
> PersistencyStragegy persistencyStrategy = new FileSystemPersistence(new File("PrevalenceBase"));
> JournalStrategy journalStrategy = new JavaIOSerializableJournalStrategy(persistencyStrategy);
> SnapshotStrategy snapshotStrategy = new JavaIOSerializableSnapshotStrategy(persistencyStrategy);
> Prevayler<Root> prevayler = new PrevaylerFactory<Root>(journalStrategy, snapshotStrategy).createInstance();
> 
> PersistencyStragegy persistencyStrategy = new TransientPersistencyStrategy();
> JournalStrategy journalStrategy = new JavaIOSerializableJournalStrategy(persistencyStrategy);
> SnapshotStrategy snapshotStrategy = new JavaIOSerializableSnapshotStrategy(persistencyStrategy);
> Prevayler<Root> prevayler = new PrevaylerFactory<Root>(journalStrategy, snapshotStrategy).createInstance();
> 
> PersistencyStragegy persistencyStrategy = new FileSystemPersistence(new File("PrevalenceBase"));
> XStreamJournalStrategy journalStrategy = new XStreamJournalStrategy(persistencyStrategy);
> journalStrategy.setXMLNamespace("org:prevaler:Elements");
> SnapshotStrategy snapshotStrategy = new JavaIOSerializableSnapshotStrategy(persistencyStrategy);
> Prevayler<Root> prevayler = new PrevaylerFactory<Root>(journalStrategy, snapshotStrategy).createInstance();
> 
> 
> 27 maj 2013 kl. 15:30 skrev Klaus Wuestefeld:
> 
> > Hi Karl, the factory has many methods. Would we duplicate all of them
> > per serialization strategy? Or would we use the abstract serializer
> > approach?
> >
> >
> > On Mon, May 27, 2013 at 4:53 AM, Karl Wettin <[email protected]> wrote:
> >>
> >> 27 maj 2013 kl. 02:38 skrev Klaus Wuestefeld:
> >>
> >>>> Personally I like all-in-one things (even with unnecessary stuff)
> >>>
> >>> Yes. I think its easier for advanced users to remove the xstream
> >>> dependency if they ant to than for noobs to include the factory
> >>> dependency.
> >>
> >> I'm more for one Factory per serialization strategy.
> >>
> >>
> >>                karl
> >>
> >> ------------------------------------------------------------------------------
> >> Try New Relic Now & We'll Send You this Cool Shirt
> >> New Relic is the only SaaS-based application performance monitoring service
> >> that delivers powerful full stack analytics. Optimize and monitor your
> >> browser, app, & servers with just a few lines of code. Try New Relic
> >> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> >> _______________________________________________
> >> To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> >> _______________________________________________
> >> "Databases in Memoriam" -- http://www.prevayler.org
> >
> >
> >
> > --
> > Valeu, Klaus.
> >
> > ------------------------------------------------------------------------------
> > Try New Relic Now & We'll Send You this Cool Shirt
> > New Relic is the only SaaS-based application performance monitoring service
> > that delivers powerful full stack analytics. Optimize and monitor your
> > browser, app, & servers with just a few lines of code. Try New Relic
> > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> > _______________________________________________
> > To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> > _______________________________________________
> > "Databases in Memoriam" -- http://www.prevayler.org
> 
> 
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> _______________________________________________
> "Databases in Memoriam" -- http://www.prevayler.org
> 
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service 
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
> To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> _______________________________________________
> "Databases in Memoriam" -- http://www.prevayler.org

-pb

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2

_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org