On 10/24/06, David Blevins <[EMAIL PROTECTED]> wrote:
Nice changes. You're a coding maniac all of the sudden! You feeling
ok? ;)
Yeah, pretty much ok (how would you call Dave, Dain, Aaron and others,
then, huh? ;-)) Figured out that the only way to catch up with you
guys is to keep coding all the time. No day with no coding! Even a
very simple shot in the dark can do the wonders. The reason I've been
quiet for such a long time has turned out to be my never-ending urge
for high quality of the code of mine. It was nearly impossible to
write anything as I couldn't satisfy myself (not to mention you), so
having followed so many contribution decided to give it a try and see
how it could work for me. I'm having lots of fun doing it and am
really going to get up to speed soon to start working towards EJB 3.0
compliancy. I do feel I can do it really, really soon. Just I need
some time revving up.
For the longest time i've wanted to encapsulate that version info
properties object with a strongly typed object. i.e.
versionInfo.getDate(), versionInfo.getTime(), versionInfo.getVersion
(), and so on. Since we moved to SVN as well, I've always really
really wanted to have the svn revision printed out as well. If you
want to work on any of that, that'd be awesome.
That's funny! I've been thinking about it lately, too, and even came
across a solution how to get svn revision with m2. Keep these
suggestions comming so I won't lose interest halfway ;-)
> URL: http://svn.apache.org/viewvc/incubator/openejb/trunk/openejb3/
> container/openejb-core/src/main/java/org/apache/openejb/alt/config/
> Deploy.java?view=diff&rev=467149&r1=467148&r2=467149
> ======================================================================
> ========
> --- incubator/openejb/trunk/openejb3/container/openejb-core/src/
> main/java/org/apache/openejb/alt/config/Deploy.java (original)
> +++ incubator/openejb/trunk/openejb3/container/openejb-core/src/
> main/java/org/apache/openejb/alt/config/Deploy.java Mon Oct 23
> 15:10:17 2006
> @@ -27,7 +27,6 @@
[...]
> } else if (args[i].equals("-l")) {
> if (args.length > i + 1) {
> - System.setProperty("log4j.configuration",
> args[++i]);
> + system.setProperty("log4j.configuration",
> args[++i]);
> }
> } else if .....
Note that if someone actually uses the -l option it won't work as
log4j will be looking in the system properties. This is part of the
tricky bits that I was mentioning the other day. I'm totally on the
fence as what to do with this one, maybe you have some ideas.
The basic options for code that needs to set actual system properties
are either 1) have code that use System directly or 2) have
SystemInstance "know" when to do that for them and do it for them.
The downside of #1 is it's perhaps a bit messy having
System.getProperty and SystemInstance.getProperty usage right next to
each other. Seems it'd be awfully easy to make a mistake and use the
wrong one.
You were leaning towards #2 in your PropertiesService class where it
would delegate to the System properties if not found in the
SystemInstance, and I generally liked the idea. The parts that makes
me wonder if it's too complicated are:
Get/set symmetry:
I.e get and set should be identical. So set would have to be
coded to know in advance what properties to pass through to the
System properties and which to keep for itself.
si.getProperties().[gs]etProperty() and si.[gs]etProperty() symmetry:
I.e. these two should behave exactly the same..
systemInstance.getProperty("log4j.configuration")
systemInstance.getProperties().getProperty("log4j.configuration")
As should these..
systemInstance.setProperty("log4j.configuration", foo)
systemInstance.getProperties().setProperty("log4j.configuration",
foo)
I think I still like the #2 better but it'd be more work. What do
you think?
Good idea! Let me finish some stuff wrt the deploy code and will get
back to it (or most likely I'll change it in the meantime). You know,
the more you write the more ideas spring into your mind. I like
reading I'm following what you've been thinking about. I'm step
beyond, but am really *mad* to change it ;-)
> + * TODO: There must be a better way to read command line args
> and spawn a command
There's always a better way to do anything. What did you have in mind?
E.g. commons-*. I've seen Jason's ideas in gshell around it that I'm
going to borrow. Just give me a few days and you'll see it yourself.
Just a nice trick so people can specify -D stuff anywhere on the
command line. Stole the idea from Maven. I.e. these use the same
technique:
openejb start -Dopenejb.localcopy=false
maven clean build -Dmaven.test.skip=true
Yeah, figured it out just few minutes ago when poking around in the
deploy command. I'm not very happy with it, though. Some other
technique is what I'd be confortable with.
> + // FIXME: Why is Exception thrown at all? It's almost
> impossible that it'll happen.
I don't recall why I did that. I must have written then yanked some
code in the constructor that threw an exception and just left the
throws claus in. I do that sometimes. Feel free to yank it too.
Thanks! Will do with a great pleasure! ;-)
> + public boolean isPropertySet(String propName) {
> + return this.properties.get(propName) != null;
> }
I like this. What do you think about renaming it to 'hasProperty'?
Way better than mine. I couldn't come up with a better name for it and
left myself with the ugly isPropertySet. I knew it wasn't only me who
might not like it ;-) Glad you've rised it up.
I've been disliking the SystemInstance.init method more and more.
I'd really like to kill it but i seem to recall some part of the
tomcat integration really needed it, but I really don't remember the
details. If that's something you want to experiment with, that'd be
cool. Just make sure you build the assemblies run the "maven itest"
on the tomcat ones if you do.
Sure. I hope I won't forget - I don't want to break anything that
works well (I'll probably need to stick another note to my computer
screen to keep that in mind, though ;-)
That's all from me for now, just random thoughts.
I really really appreciate them! I read them with great delight and
expect more to come. Thanks!
(not much time tonight yet to work on OpenEJB, but would like to see
some JUnit 4.1 tests in)
Jacek
--
Jacek Laskowski
http://www.jaceklaskowski.pl