The more I dig, the more I see you're right, Ben. (Good to hear from you by the way!)
In PDFStreamEngine.ProcessOperator, I'll call the OperatorProcessor's setContext to pass a handle to the engine. In the Invoke.process I'll pass the graphics state's handle on down to the PDXObjectImage ... in a new property. I think that will get it. Think I'm messing anything up with that? Thanks! Daniel Wilson On Thu, Apr 23, 2009 at 8:18 PM, Ben Litchfield <[email protected]>wrote: > Singletons should be used with caution and I don't think we want one here, > PDFBox would not be able to be used in a multi-threaded server environment, > which is currently the case. There must be a way to pass either the color > itself, the engine or the graphics state(probably the best) to the methods > that need it. > > Ben > > > > Daniel Wilson wrote: > >> I should have read that article more carefully the first time. The >> problem >> I feared very definitely exists. So I'm not checking this code in! >> >> Alternate solutions anybody? >> >> Thanks! >> >> On Thu, Apr 23, 2009 at 7:20 PM, Daniel Wilson < >> [email protected]> wrote: >> >> >> >>> I have accomplished what I needed by borrowing from the Singleton idea, >>> my >>> pattern being >>> http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html >>> >>> I have a private variable called instance, a public getInstance() method >>> that checks whether it's instantiated and returns it, and the >>> constructors >>> are now protected. >>> >>> But it's not a true Singleton because the descendants (PageDrawer, >>> PDFTextStripper, etc.) still have public constructors. >>> >>> In a single-threaded environment, I don't think that matters. I think it >>> is practically a singleton in those situations. >>> >>> But what about a multi-threaded environment? >>> >>> class AlmostSingleton{ >>> private static AlmostSingleton instance; >>> protected AlmostSingleton(){ >>> instance = this; >>> } >>> public AlmostSingleton getInstance(){ >>> if (instance == null) instance = new AlmostSingleton(); >>> return instance; >>> } >>> } >>> >>> class Child1 extends AlmostSingleton{ >>> public Child1() { >>> //do whatever in constructor >>> } >>> } >>> >>> Now ... if 2 different threads instantiate Child1 and call getInstance(), >>> are they looking at the same instance or different ones? >>> >>> If the same, my static getInstance() causes a real problem. >>> >>> Making the descendants of PDFStreamEngine have private / protected >>> constructors would break a lot of client applications. Obviously we >>> can't >>> go there. >>> >>> >>> On Thu, Apr 23, 2009 at 2:10 PM, Daniel Wilson < >>> [email protected]> wrote: >>> >>> >>> >>>> I am working through the implementation details of making >>>> PDFStreamEngine >>>> a singleton. >>>> >>>> I would like to do so because I need for the PDXObjectImage to be able >>>> to >>>> get the current nonstroking colorspace. >>>> >>>> The call >>>> *CS = >>>> >>>> PDFStreamEngine.getInstance().getGraphicsState().getNonStrokingColorSpace(); >>>> * >>>> would solve this very nicely. >>>> >>>> My understanding is that there is really only one PDFStreamEngine (or >>>> descendant thereof) in existence (within a particular thread's context) >>>> anyway. >>>> >>>> Does anyone see a problem with making PDFStreamEngine a singleton? A >>>> big >>>> theoretical problem, a reason it should not be attempted? >>>> >>>> I think I can work through the implementation details, as I said. And I >>>> will certainly run the junit tests to make sure the thing behaves in all >>>> our >>>> defined scenarios. >>>> >>>> Thanks! >>>> >>>> Daniel Wilson >>>> >>>> >>>> >>> >>> >> >> >> > >
