> > This is unfortunate that my changes to WebMacroService required
> > modification of WebMacro itself. The patch is tiny and I my opinion
> > makes good sense, so it should be possible to get it into upstream
> > WebMacro.
>
> Hopefully - yes. The status of WM seems to be very undefined at the
> moment. I made a patch for WM that allows us to use the WM ContextTool
> API for out context tools but as far as I know Jon hasn't been able to
> get onto shimari.com CVS to put it in.
All this mess with Semiotek, their CVS and their behaviour really disturbes me...
Still, there are other solutions to this problem that don't require modification
of WM jar. We could implement TurbineTemplateProvider that uses WebMacro
service's configuration to determine templates path. This is easy to do.
> > I would like to raise another proposal when we are talking
> about service names.
> > I believe that services should be called 'Whatever' instead
>
> of 'TurbineWhateverService'.
> This certainly sounds sensible to me, ad I guess if you're going to go
> gratuitously breaking stuff now is a good time :-)
Actually, it doesn't require as much breaking stuff as you think. Some of you
guys was really thinking in advance, and service names aret't strings scattered
all around the code - they are final static Strings in the interfaces. Therefore
changing them is very easy. The bad thing is, that services aren't consistent
about the name of the string. ShedulerService uses SCHEDULER,
FreeMarkerService uses SERVICE_NAME, and XmlRpcService uses
XMLRPC_SERVICE_NAME. I suggest that we should change these interfaces
to use SERVICE_NAME.
I ran a quick grep, and there are 34 invocations of getService throughout the code.
Definetely possible to cope with.
This is a relatively widespread change though, so I'm waing for any objections unitl
tomorrow.
> > There is another thing about the code I wrote. It is not
> thread safe. The old code
> > wasn't either (or I really overlooked something). And I
> believe it should be.
> > Anyway, I have very litle experience with concurrent
> programing, so I don't
> > feel competent to implement it. If you are - step out and
> finish this work.
>
> Can you elaborate on what you think is not thread safe? AFAIK stuff in
> init() doesn't have to be and you've got the first time request stuff
> wrapped with the Turbine class-object lock.
It sure makes sense that Servlet.init() is not called by two threads concurrently,
I didn't have time to check the documentation, but I think we can assume this is
safe. Wrapping firstDoGet with class wide lock seemed obvious to me, because
how could I otherwise state that this is really the first invocation? Requests can
arrive frequently... It looks like this isn't going to break for us. But if we want
this code do be more general, it could use some improvement.
It's easy to tell that BaseInitiableBroker.initClass(Object) shouldn't be called by
two threads concurently - it has internal state (the stack) that could be easily
corrupted. I think it is justifable to make this method synchronized (as far as I
understand this stuff). The other thing that we should consider is, whether
init(something) and init() methods of Initable are idempotent. To put it other way:
do we guarantee that init() method of an Initable will be called exactly once.
It would be easier for us to delegate this problem, and any threading issues
arising from it to the Initable class in question ;). But if we want to make warranties
regarding calling init() locking is probably neccessary near if(!initablegetInit()) {
initable.init() }
sequence.
Rafal
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
