Re: Optimizing the OpenEjb modules discovery

[Quintin Beukes <qu...@skywalk.co.za>]

Quintin Beukes

> Stripping them off, logging a warning that we did so, and including the
> configurable flag in the warning seems like the way to go.  We might want to
> do that for all properties.
>

Since reading Properties literally, quotes and all, is standard (because
they are handled on a line-by-line basis), it might be a good idea to
implement this as a sort of "extension" on the standard OpenEJB, then make
the configuration flag default to "enabled=true". This way it can be seen,
when "enabled=false" that the extension is disabled, leaving a "cleaner"
OpenEJB. So it can be viewed as OpenEJB itself following the Java
conventions/standards, with an extension to add the "slash stripping"
functionality.

It doesn't really make a difference to the functionality. I just thought i'd
suggest it. It comes down to viewpoint, so instead of "enabling the standard
way", you "disable the non-standard way extension". Even though it's enabled
by default, it seems a bit more acceptable for extensions to break away from
the standards, instead of extensions enforcing the standards.

I don't know how to explain my justification for this, so I hope you
understand.

Q

Re: Optimizing the OpenEjb modules discovery

[David Blevins <da...@visi.com>]

On Nov 3, 2009, at 11:44 AM, Quintin Beukes wrote:

> Quintin Beukes
>
>> Stripping them off, logging a warning that we did so, and including  
>> the
>> configurable flag in the warning seems like the way to go.  We  
>> might want to
>> do that for all properties.
>>
>
> Since reading Properties literally, quotes and all, is standard  
> (because
> they are handled on a line-by-line basis), it might be a good idea to
> implement this as a sort of "extension" on the standard OpenEJB,  
> then make
> the configuration flag default to "enabled=true". This way it can be  
> seen,
> when "enabled=false" that the extension is disabled, leaving a  
> "cleaner"
> OpenEJB. So it can be viewed as OpenEJB itself following the Java
> conventions/standards, with an extension to add the "slash stripping"
> functionality.
>
> It doesn't really make a difference to the functionality. I just  
> thought i'd
> suggest it. It comes down to viewpoint, so instead of "enabling the  
> standard
> way", you "disable the non-standard way extension". Even though it's  
> enabled
> by default, it seems a bit more acceptable for extensions to break  
> away from
> the standards, instead of extensions enforcing the standards.
>
> I don't know how to explain my justification for this, so I hope you
> understand.

Right, so I was thinking we could add the quote-stripping logic right  
into our SuperProperties class.  It has some other neat things like  
case-insensitive keys and whatnot.

The flag we can add elsewhere.  Finding a good name for the flag is  
always a trick. "openejb.properties.unquote" or something?

The part that isn't clear to me is where to put the logging.   
SuperProperties is designed to be a simple utility and not dependent  
on an logging, it's actually used far before logging is even "running"  
so to speak.  Some ideas there would be great.  Maybe the quote  
stripping logic is best done elsewhere?

Anyway, brainstorming as well.

-David