looking what we have today in standalone mode i think exceptions are useless: people can (should) split their applications into packages correctly IMHO. Managing classes and packages is (still IMHO) not interesting for the same reason. For me include/exclude pattern like in standalone should be enough: it is not a standard feature it is simply a helper feature, regexp should really be enough (often people will include easily jars with regexp or with few "or package pattern").
Another point but i'm less sure i understand what you want to do: do you want to add an xml for it? couldn't it be included in openejb.xml (in containers for example) or as context-param for webapp and system properties for standalone mode? - Rniamo On Thu, Mar 24, 2011 at 10:36 PM, David Blevins <[email protected]>wrote: > Started to type this in the previous email and wow did it get too long.... > > In general I'm still not sure what kind of properties we might want to use > to configure all this. Here's a sample of the xml I imagine: > > An include based approach: > > <scanning> > > <includes> > > <package>org.superbiz</package> > <package>org.wonderbiz</package> > <class>com.techie.Widget</class> > > <exceptions> > <package>org.superbiz.util</package> > <class>com.superbiz.Foo</class> > <pattern>.*Test</pattern> > </exceptions> > > </includes> > > </scanning> > > An exclude based approach: > > <scanning> > > <excludes> > > <pattern>org.*</pattern> > > <exceptions> > <package>org.superbiz</package> > <package>org.wonderbiz</package> > </exceptions> > > </excludes> > > </scanning> > > Let me get straight to the point and say I'm not sure an exclude based > approach is useful. Factually, whichever has the fewest rules will be > faster. Our current classpath filtering has a lot of built-in rules we turn > on if you change the default settings, and is hence a little slow if you > actually use it. > > > I copied the Include+Exclude vs Exclude+Include from HTTPD. They call it > Allow,Deny vs Deny,Allow. The names and descriptions are not great and > people clearly misunderstand them. Here's how they have them documented: > > Ordering is one of: > > Allow,Deny > > First, all Allow directives are evaluated; at least one must > match, or the request is rejected. Next, all Deny directives are > evaluated. If any matches, the request is rejected. Last, any > requests which do not match an Allow or a Deny directive are > denied by default. > > Deny,Allow > > First, all Deny directives are evaluated; if any match, the > request is denied unless it also matches an Allow directive. Any > requests which do not match any Allow or Deny directives are > permitted. > > The descriptions are OK enough, but the names imply the opposite in my > brain. They seem to conflict in my reading of them because there are > actually THREE levels of things going on. What the default behavior is is > NOT in the name. It should be something like: > > Default Deny, Allow, Deny > > First, all Allow directives are evaluated.... > > Default Allow, Deny, Allow > > First, all Deny directives are evaluated.... > > As a result of the default not being in the name and the topic being > somewhat confusing, you can find tons of blog posts from people advising > using "Deny,Allow" with a DenyAll rule. It feels good to have deny listed > first in your ordering and it feels great to *see* "Deny All" as rule, but > what you've actually done is: > > Default Allow, Deny All rule, Allow rules > > You just lost one of your three levels. That very last level is meant to > allow you to configure exceptions to your rules. So I don't think they > should be called "Deny,Allow" but simply referred to as they are: > exceptions. That gives you: > > Default Deny, Allow rules, Allow rule exceptions > > First, all Allow directives are evaluated.... > > Default Allow, Deny rules, Deny rule exceptions > > First, all Deny directives are evaluated.... > > If people actually had to *see* Default Allow sitting next to Deny All, > they'd probably be more inclined to read the docs better. > > > Anyway I'm not sure you ever really need both. The most useful to our > situation is likely Default Deny, Allow Rules, Allow Rule Exceptions. Or in > our terms, Default Exclude, Include Rules, Include Rule Exceptions. > > Implementation-wise it's extremely easy to support both. They're one or > two lines of code different. But... > > Configuration and documentation wise, I'm not sure that we want to present > it all or how to present it all. If we do accept both we should definitely > flag situations were people make the above mistake. > > > Open to any thoughts on how to expose the possibilities in both property > and xml forms. > > > I'm somewhat leaning towards only ever showing and documenting an default > deny, includes, include exceptions approach and just have the inverse > (default allow, excludes, exclude exceptions) be something that's just there > and we don't mention unless someone complains. > > Technically speaking, whatever has the fewest rules will perform the best. > > > -David > > > > >
