On Sun, Aug 31, 2008 at 6:13 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: >> >> On Sun, Aug 31, 2008 at 2:59 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >>> >>> Robert Burrell Donkin (JIRA) ha scritto: >>>> >>>> * Entry point: >>>> * SieveFactory >>> >>> This should only be used to wire together the default implementations, >>> otherwise direct objects wiring should be allowed for >>> extensibility/integration. >> >> i see no reason why SieveFactory needs to be coupled to the default >> implementations. the factory should be either abstract or an interface >> and loaded by the configuration. > > My think is that if it is an entry point it cannot be abstract or an > interface. The entry point is the object I instantiate to use sieve (in my > terms). > But I guess here we are simply using different terms. It's better I wait and > look at how you will change code and maybe I should better speak with code > in reply :-)
SieveFactory is currently the (badly named) entry point. it might be better to have a proper factory as the entry point. >> i'm not sure it's worthwhile to create yet another logger bridge in >> this case. injecting a JCL log is probably good enough. > > My issue with JCL injecting is that Logger does not have a getChildLogger. yes - that's probably the biggest mistake we made when creating the API. then again, the JEE specifications weren't broken at that time so it didn't seem necessary to cater for injecting loggers. > So if you inject a JCL logger you can't have different names in the various > components. jsieve doesn't need this functionality > Furthermore there are many people not happy with commons-logging, and they > often don't understand the difference between injected commons-logging and > static commons-logging usage. The bad name for loggers born by their static > usage. i strongly suspect that JCL is the most widely used library in java. lots of people whinge but everyone uses it. the JEE specifications are mutally incompatible when it comes to classloaders. this makes it impossible to fix JCL or come up with anything better than it that is compatible with both the servlet and enterprise specifications. it's problems are well known as are the workarounds. alternative solutions often have better reputations because no one really uses them. the JCP is absolutely culpable for the whole mess. they refused to invite ceki onto the expert group for java.util.logging and so forced people to choose between log4j and java.util.logging. this forced JCL to be created. the JCP then decided that it was more important that JEE engines could do whatever they want with classloaders than consistency with the Java2 or servlet specifications. this caused the classloading hell with JCL and made it impossible to fix for both servlet containers and JEE containers. <snip> >>> About thread safety I think the goal should be to have the whole script >>> execution reentrant so that a single instance of a parsed script can be >>> used >>> by multiple threads. >> >> +1 >> >>> Parsing instead can be thought to happen in a single thread. >> >> it's an atomic function: parsing produces a executor > > I meant it can be synchronized. IMHO making this atomic function thread safe > does not worth it. If someone have to really parse multiple scripts with > multiple threads they can use multiple parser instances. by atomic function i mean one that takes an input and produces an output without mutating state variables. synchronisation is not necessary providing the function has no side effects. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
