You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Jon Stevens <jo...@latchkey.com> on 2001/03/06 00:22:56 UTC
[Proposal] Velocity Release Plan 1.0
Hey all,
Velocity is doing extremely well. The code is working well and a number of
us are relying on it for our projects. Therefore, I propose that we start
working towards a release plan for a 1.0 version. We will have two beta's a
week apart and a final release.
Here is the goals:
Velocity 1.0b1 - Monday, March 18th, 2001
This version will be our first official release. It will include all of
the current code to date. The core code will be declared stable and
after 1.0b1, there will only be bug fixes and no more feature additions
util the next major release.
Velocity 1.0b2 - Monday, March 26th, 2001
Any bugs that have been found between b1 and the next week will be
fixed and a new release will occur. In this release, people should
report that all bugs from the previous release have been confirmed as
fixed.
Velocity 1.0 - Monday, April 2nd, 2001
Velocity 1.0 release.
The voting period will end at midnight on Tuesday March 6th, 2001. I will
post the vote tally later that day.
<----- Please return this portion with your vote ----->
[ ] +1 I am in favor of this plan and will help
[ ] +0 I am in favor of this plan, but am unable to help
[ ] -0 I am not in favor of this plan
[ ] -1 I am against this plan being executed, and my
reason is:
<----------------------------------------------------->
For approval, there must be at least three +1 votes by Committers,
and more +1 votes than -1 votes.
thanks,
-jon
Re: [Proposal] Velocity Release Plan 1.0
Posted by Jason van Zyl <jv...@periapt.com>.
>
I have also posted to the alexandria group trying to get a copy of
alexandria running on apache.org box so that the javadocs will
be available online for launch. We can do this manually if
necessary but it would be to have alexandria do it.
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
Re: [Proposal] Velocity Release Plan 1.0
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
> <----- Please return this portion with your vote ----->
> [X] +1 I am in favor of this plan and will help
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Release 1.0 TODO
Posted by Jason van Zyl <jv...@periapt.com>.
Dave Bryson wrote:
> On Tue, 06 Mar 2001, you wrote:
> >
> > o Getting a mailing list archive working, or at least have
> >
> > PLAN:
> > Can we setup Eyebrowse? Would this be too much of a PITA,
> > or would be too tempted to convert it to Velocity :-)
> > If no one has time for this, can we at least place
> > a message at the bottom of messages that go out
> > on the mailing list?
> >
> > STATUS:
> > None
>
> I think this would be very useful. I have not setup Eyebrowse before
> but i'll led a hand where i can.
Maybe we can attempt together, I'm not sure how easy it is or
Jon probably would have set it up. But it uses WebMacro :-)
I think I would be tempted to make it use Velocity if I tried
setting it up!
I would be happy with a pointer to mail-archive.com if
EyeBrowse is a hassle to set up. I know everyones is swamped.
>
>
> > o Test for Anakia
> >
> > PLAN:
> > Just add a simple test for Anakia to make sure things
> > don't break when changes are made.
> >
> > STATUS:
> [Daveb] I'll do this, unless someone else has dibbs.
Great! Can you update the todo-1.0 document in CVS please :-)
>
>
>
> > o Codify the testing harness
> >
> > PLAN:
> > Have a single target that runs the whole set of
> > tests. Right now the main test is the template testing,
> > it would be nice to run all the tests in there.
> >
> > STATUS:
> > None
>
> A couple of the tests ( cpload,multi ) set a loader. Is it possible to change
> the loaders on the fly?
No, but that's definitely something to think about! Would need
some security measure, but it would be neat to be able to add
loaders in a running app. Something for later :-)
>
>
> --
> Dave Bryson
> daveb@miceda-data.com
> ----------------------
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
Re: Release 1.0 TODO
Posted by Dave Bryson <da...@miceda-data.com>.
On Tue, 06 Mar 2001, you wrote:
>
> o Getting a mailing list archive working, or at least have
>
> PLAN:
> Can we setup Eyebrowse? Would this be too much of a PITA,
> or would be too tempted to convert it to Velocity :-)
> If no one has time for this, can we at least place
> a message at the bottom of messages that go out
> on the mailing list?
>
> STATUS:
> None
I think this would be very useful. I have not setup Eyebrowse before
but i'll led a hand where i can.
> o Test for Anakia
>
> PLAN:
> Just add a simple test for Anakia to make sure things
> don't break when changes are made.
>
> STATUS:
[Daveb] I'll do this, unless someone else has dibbs.
> o Codify the testing harness
>
> PLAN:
> Have a single target that runs the whole set of
> tests. Right now the main test is the template testing,
> it would be nice to run all the tests in there.
>
> STATUS:
> None
A couple of the tests ( cpload,multi ) set a loader. Is it possible to change
the loaders on the fly?
--
Dave Bryson
daveb@miceda-data.com
----------------------
Release 1.0 TODO
Posted by Jason van Zyl <jv...@periapt.com>.
Hi Guys,
Here's a revamped TODO list. Can anyone add whatever they
think is necessary? Can we do this by tomorrow evening and get
things finalized? People can just post items to the list if they like
and I will keep track of things. I will be in and out today but I
be around in spurts to keep track of the TODO.
So have a full list by tomorrow evening, then decide what will
be done and then truck along?
Any thoughts? Any problems?
jvz.
o Configuration Cleanup
PLAN:
We're still debating.
STATUS:
[JVZ] I will make the changes when and if we agree.
o Log4j for Logging
PLAN:
Simply replace the org.apache.log package for now. Just
a flat replacement for the features that log4j provides.
The logging interface can come later.
STATUS:
[JVZ] I will do this if we can agree on this.
o Get a copy of Alexandria for Javadocs
PLAN:
It would be ideal to get a copy of Alexandria running
on the apache.org box. But we can do it manually if
necessary.
STATUS:
[JVZ] I have asked on the Alexandria mailing list to
to see if someone will look into setting up Alexandria
but I have heard anything back yet. PLAN:
Use a tool to reverse engineer the code in XMI so we have
something to play with in Argo.
STATUS:
Ilkka Priha has made us a set of XMI files for Velocity,
I will check them into CVS and we can go from there.
o Getting a mailing list archive working, or at least have
PLAN:
Can we setup Eyebrowse? Would this be too much of a PITA,
or would be too tempted to convert it to Velocity :-)
If no one has time for this, can we at least place
a message at the bottom of messages that go out
on the mailing list?
STATUS:
None
o Test for Texen
PLAN:
Just add a simple test for Texen to make sure things
don't break when changes are made.
STATUS:
[JVZ] I will add the test for Texen.
o Test for Anakia
PLAN:
Just add a simple test for Anakia to make sure things
don't break when changes are made.
STATUS:
None
o Codify the testing harness
PLAN:
Have a single target that runs the whole set of
tests. Right now the main test is the template testing,
it would be nice to run all the tests in there.
STATUS:
None
o Grinder for Velocity
PLAN:
Create a grinder that will stress velocity and report
performance so that anyone interested in trying to
improve the speed of Velocity can easily try and
use the grinder to check the results.
STATUS:
None
Re: [Proposal] Velocity Release Plan 1.0
Posted by Daniel Rall <dl...@collab.net>.
"Geir Magnusson Jr." <ge...@optonline.net> writes:
> I think that we really should consider this decision carefully. I
> really like having the options of using the Properties to load - since I
> would bet that the Properties class is very common for people to use in
> their own apps, every java101 programmer understands how to use it, etc,
> etc, etc
>
> The multi-key problem only surfaced recently with the multi-node
> template and jar paths, and that was solvable in the same way WM solved
> it, by letting the property be free form, and letting the entity that
> required multi-valued properties to parse in the way it needs.
>
> Everything that we want to do could be achieved with the
> java.util.Properties. If Configuration makes life easier internally to
> justify the added code, then I am all for it, but I still think that we
> should support the standard Properties object as a full functional
> method of init.
I'm with Geir on this one. I like the concept of sticking with a
regular Properties object, and letting the consumer of that properties
object tokenize as necessary. This presents a simple, friendly
interface while still being flexible enough to associate multiple
values with one key.
> > o UML Diagrams: Even if they are quick it would be nice to have. I
> > have asked a Turbiner (Ilkka Priha) if he could reverse engineer a
> > set of diagrams like he did for Turbine.
As I mentioned on the Turbine list, I'd like to Argo-ify whatever
Ilkka's commercial product generates.
--
Daniel Rall <dl...@collab.net>
Re: [Proposal] Velocity Release Plan 1.0
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Since this is getting complicated, let me summarize where I am coming
from. I will answer Jason's comments inline after.
Premise : I don't think we should eliminate java.util.Properties as a
mechanism for initializing Velocity. This is not an internals agument -
we can do what we need to internally as long as we don't hang ourselves
in the process. It is a 'public interface' discussion, and I think our
public requirements and usage patterns should be as conventional as
possible if there is no downside to doing so.
I believe that the current options of initialization
Runtime.init() : uses defaults
Runtime.init( filename ) : defaults + props in the file
Runtime.init( Properties ) : defaults + props in the Properties
are complete, although I am all for an addition of a fourth
Runtime.init( Configuration ) : defaults + propse in the Configuration
(not impl yet)
if people want that.
I want it to be clear - it's not "Properties exclusive of all else" - as
a user (and as a consultant, recommending Velocity on commercial clients
), I think the Properties support is important.
Note also that orbiting this discussion is a set of methods that Turbine
uses for initialization.
Some reasons :
* java.util.Properties is a standard Java class that ever programmer is
familiar with
* java.util.Properties is already used in applications to hold
configuration information, so supporting this helps in integration into
existing systems. For example, Turbine uses a Properties (although it
uses a special API to set specific Velocity properties before init().)
* Using a standard properties mechanism like this makes Velocity more
immediately 'familiar' to people using Velocity. There isn't a new
class, no matter how easy, to learn, slightly lowering the learning
curve.
* we have supported using a Properies object for initialization since
November, and we haven't run into any problems
I believe that this issue came to be because:
* to support multiple template paths, it is necessary to have a
'multi-valued property' in order to have some sort of mechanism to hold
the path elements. There were three possibilities to express this:
# use a multi-valued property (quibble about separator later)
resource.loader.1.resource.path = <dir1>,<dir2>,<dir3>
# use distinct scalar properties
resource.loader.1.resource.path.1 = <dir1>
resource.loader.1.resource.path.2 = <dir2>
resource.loader.1.resource.path.3 = <dir3>
# use identical scalar properties
resource.loader.1.resource.path = <dir1>
resource.loader.1.resource.path = <dir2>
resource.loader.1.resource.path = <dir3>
and the one that can't be supported by a Properties, the third, was
chosen. The other two methods would work fine via a Properties, and
further have the benefit that it's clear to the casual reader what is
going on.
An argument was made that Turbine would have to change a little to deal
with this. I don't think it would be that hard, quite frankly, and am
offering my commitment to help work things out.
It's not entirely clear that Configuration as a 'SuperProperties' is
easy for anyone to just use - the issue with scalars being turned into
vectors when set again may be just a bug. I am not sure.
more inline...
Jason van Zyl wrote:
>
> "Geir Magnusson Jr." wrote:
>
> > Jason van Zyl wrote:
> > >
> > > "Geir Magnusson Jr." wrote:
> > >
> > > > [SNIP]
> > > > Can we just support both then? The 'same value key' problem is somewhat
> > > > artificial, because you and john wanted to do, for multiple paths,
> > > >
> > > > path = foo
> > > > path = bar
> > > > path = woogie
> > >
> > > Which is equivalent to
> > > path = foo,bar,woogie
> > >
> > > With the Configuration class, and we wanted it because we use
> > > that in turbine and the classes have been used for a long time and
> > > work.
>
> >
> > > >
> > > >
> > > > rather than
> > > >
> > > > path = foo:bar:woogie
> > > >
> > > > or
> > > >
> > > > path.1 = foo
> > > > path.2 = bar
> > > > path.3 = woogie
> > > >
> > > > (The latter way is nicer - you don't have to worry that the separator
> > > > is a valid character in the data )
> > >
> > > This will not work. The name of the property has to be the same in
> > > order to dynamically set the resource path. In Turbine we might
> > > do:
> >
> > Sorry. Of course I meant :
> >
> > resource.loader.1.resource.path.1 = foo
> > resource.loader.1.resource.path.2 = bar
> >
> > (just too lazy to type it)
> >
> > > 1)
> > > Runtime.setSourceProperty(FILE_RESOURCE_PATH, path1);
> > > Runtime.setSourceProperty(FILE_RESOURCE_PATH, path2);
> > >
> > > I do not want to have to do
> > >
> > > 1)
> > > Runtime.setProperty("resource.loader.1.file.resource.path.1", path1);
> > > Runtime.setProperty("resource.loader.1.file.resource.path.2", path1);
> > >
> > > I don't have a safe constant to work with, and the file loader might not be
> > > the first loader. If the defaults for the file resource loader get overriden
> > > then this code will break. 1) is always guaranteed to work.
> >
> > I still think that we should punt on these methods to Runtime since a
> > single call to init() can do all of this, and I think that hardwiring
> > FILE_RESOURCE_PATH as a constant isn't a good idea as it isn't safe
> > because it makes assumptions about the public.name of the loader...but
> > ignoring that, what do these really have to do with each other?
>
> We agreed that the file resource loader was a standard loader did we not?
> And as a standard loader the setting of its configuration can be set
> as it is done above. I think the class resource loader should be a standard
> loader too. With these two, I think 99% of most cases are handled.
We agreed it is the default loader specified in our default properties,
and if that changes, Turbine won't work. At the least, we should be
able to ask for the name of the 'default' loader from Velocity via a
method, or something like that - fewer assumptions. I am just worried
about what happens if something changes in the defaults....
> >
> > FILE_LOADER_RESOURCE_PATH isn't defined as
> > "resource.loader.1.file.resource.path". It is "file.resource.path",
> > which isn't a real property for configuring a loader. This is a
> > source-specific mechanism dependant upon the ResourceManager taking it
> > apart to deduce the public name of the loader. The other part
> > 'resource.path' is passed into the Configuration object handling that
> > loader, and it does the right thing, tacking it on the end. I do like
> > this hack, and the Configuration class seems rather nice, BTW.
>
> I don't consider it a hack, I think it provides the easiest way to
> embed velocity. No external velocity props is required, you
> have access to the standard loaders and you can set the
> config for the loader very easily using the constant.
All I mean is that there should be a deterministic way of doing this,
rather than relying on the public name of the file loader in the default
properties file to remain in synch with a constant in RuntimeConstants.
> >
> >
> > But, that said, making the props
> >
> > resource.loader.1.resource.path.1 = foo
> > resource.loader.1.resource.path.2 = bar
> >
> > would have no effect on that. It would require a change in loading the
> > Configuration to deal with the trailing integer, bit you already are
> > dealing with the complexity of the multiple resource loader definitions
> > and ordering.
>
> Yes it would have an effect. Turbine doesn't have a velocity properties
> file and depends on the the defaults that velocity provides. Now for
> Turbine I'm on top of the changes but with your method I would have
> to the
>
> Runtime.setProperties("resource.loader.1.resource.path.1", path1)
>
> But this requires people to dig through the source and find out
> what the defaults are to get the property right. Why should I
> have to know what that string is? I just want to set a resource
> path.
I believe you are relying on faith and prayer that the default
properties set and the string in RuntimeConstants stays the same -
futher, since the value of the constant FILE_RESOURCE_PATH is embedded
into Turbine's bytecode when compiled, if we change the value (not the
constant name, the value) in Velocity, then Turbine will have to be
recompiled. We know this - we spent hours chasing this down.
If there was a 'live' way of doing it, a method getDefaultLoader() or
something, then you could just do something like
for( int i = 0; i < mypatharr.length; i++)
Runtime.setProperties( Runtime.getDefaultLoader() +
".resource.path." + i, mypatharr[i]);
which doesn't seem too onerous. You could even hardwire a constant
RESOURCE_PATH to avoid the string.
Further, it would mean we could dump the whole setProperties() method,
and you could do something like :
Properties p = new Properties();
for( int i = 0; i < mypatharr.length; i++)
p.setProperty( Runtime.getDefaultLoader() + ".resource.path." + i,
mypatharr[i]);
Runtime.init(p);
Just as easy.
And anyway, this is a bit of a tangent. I bet we could fix it so we
keep the current hardwired token, use properties compatibile with a
Properties, and Turbine would be happy.
At least, we could make a runtime method addSourceProperty() or
something for the multi-valued ones.
> And if we decided to change the defaults, people who didn't stay
> on top of changes would find their apps broken.
Yep. And if we had a method to get this value, they wouldn't.
> So let me get this clear, apps that have no velocity properties
> are supposed use
>
> Runtime.setProperties("resource.loader.1.resource.path.1", path1)
>
> to set a resource path?
No. It should be deterministic - see above.
> >
> >
> > What I am saying is that changing the multi-path property to be as I
> > suggest would have *no* effect on the way Turbine prefers to load
> > things, or those Runtime methods in general. They wouldn't have to
> > change at all. The only thing that would change is how the
> > Configuration / Configurations / ExtendedProperties deals with the new
> > property spec.
>
> If I'm correct in how I think you want to specify a resource path
> then it certainly has an effect. But clarify this if I misunderstand.
I think what I wrote above re the for() loop should do that, but I am
happy to demonstrate how it can be done. I understand that you are
happy in Turbine depending upon the default properties in Velocity, and
I think thats fine. I do it all the time in other things.
I just think that this whole issue can be cleared up if we don't
hardwire the magic cookie for the default loader but make it accessable
via a method call [I think you would agree that is safer all around],
and make the multi-path property names distinguishable. Then Turbine
can stay the same, and our init() methods can stay the same.
> > >
> > > That's why I want to do the change now before we launch. Get
> > > rid of it now while we can!
> >
> > I just don't think we need to force everyone to use an entirely new
> > class (for everyone except Turbine - and currently, Turbine doesn't use
> > it to init Velocity, and the Velocity version isn't the same as the
> > Turbine version) to handle application-level properties specification
> > methods, since I believe (and am happy to prove) that we could easily
> > acommodate both.
>
> We're not forcing people to do anything, we haven't even released?
We would be forcing them to use a Configuration, as they couldn't use a
Properties.
> Sure you could accomdate it with free text definition of properties
> but I don't think that's a good thing. I think the constant is a much
> safer mechanism. Users of velocity will use the file loader that we
> provide and I think the way turbine uses velocity is the most
> convenient.
If you mean by 'free text', having people put in the whoel string, I
agree - 'free text' would be a bad idea.
As as for convenience, I disagree. And with a little tweak to the whole
FILE_LOADER constant business (see above), we could it could use a
Properties too. I have two clients using it in production, and both use
files or Properties to init.
And I am about to go work with a third today to integrate Velocity into
their existing production system. I will report back on how their
system deals with configuration parameters.
> How about we poll the users? I think the way turbine does it is easiest,
> you use properties. How about we ask the users?
No problem. There are more uses to this than Turbine. I am also a
user, and my clients are users :)
What are we going to ask? I think the question is important. This
whole thing exists (I believe) because of the choice made for the
multi-path property tokens, and I think we could fix it by changing
those.
> > I just don't see the downside - I think we can get everything we want at
> > once - arrange things so that we support what I suppose lots of Java
> > programmers (including the person who wrote TurbineVelocityService) use
> > for application configuration... java.util.Properties.
>
> If I have to use free text definition of properties then I definitely
> have a problem with it.
First, I don't want to, nor could I, force you as a Turbine user to do
anything you don't want to do, as long as Turbine doesn't force Velocity
in a direction away from general-ness, I don't care what Turbine does.
Second, Turbines method of init is a separate issue - if we can have
Properties-compaitible properties, and turbine can still use its
approach, would you be satisfied?
Just to be clear, how do you define 'free text'? Strings in code? I
agree - bad idea.
> >
> >
> > > > > >
> > > > > > Everything that we want to do could be achieved with the
> > > > > > java.util.Properties.
> > > > >
> > > > > I don't think so, the Properties class doesn't behave the way the
> > > > > Configuration class does and it's the Configuration class that has
> > > > > always been the core configuration class. To make a Properties
> > > > > class work with the Configuration class you would have to add
> > > > > a hack in the runtime to parse CSV lines when the Configuration
> > > > > class does this already.
> > > >
> > > > Or if we made a simple change to what a multi-path spec is, to
> > > >
> > > > path.1 = foo
> > > > path.2 = bar
> > > >
> > > > wouldn't the issue just go away?
> > >
> > > No, as explained above.
> >
> > I wasn't convinced - see above.
> >
> > > >
> > > >
> > > > > > If Configuration makes life easier internally to
> > > > > > justify the added code, then I am all for it, but I still think that we
> > > > > > should support the standard Properties object as a full functional
> > > > > > method of init.
> > > > >
> > > > > Just for the record, I don't consider the using a Properties object to
> > > > > init the runtime the standard way. The app that has been using Velocity
> > > > > the longest, turbine, has never used this method.
> > > >
> > > > And looking at TurbineVelocityService, it uses a Properties internally
> > > > (so some apps *do* use the Properties class for configuration
> > > > management), and knows where its properties file is. I think the
> > > > following code would make Turbine compatible with using j.u.Properties
> > > > to initialize :
> > >
> > > It doesn't work the way you think it does.
> >
> > Ok. I figured that I messed it up somewhere - The current Turbine code
> > is :
> >
> > /*
> > * Get the properties for this Service
> > */
> > Properties props = getProperties();
> >
> > String vProperties = TurbineServlet.getRealPath(
> > props.getProperty("properties", null));
> >
> > String vLog = TurbineServlet.getRealPath(
> > props.getProperty("log", null));
> >
> > String vTemplates = TurbineServlet.getRealPath(
> > props.getProperty("templates", null));
> >
> > [SNIPPING UNRELATED CODE FOR BREVITY]
> >
> > try
> > {
> > Runtime.setProperties(vProperties);
> > Runtime.setSourceProperty(Runtime.FILE_RESOURCE_LOADER_PATH,
> > vTemplates);
> > Runtime.setProperty(Runtime.RUNTIME_LOG, vLog);
> > Runtime.init();
> > encoding = Runtime.getString(Runtime.TEMPLATE_ENCODING);
> > Log.info("VelocityService: encoding=" + encoding);
> > }
> > catch(Exception e)
> > ...
> >
> > And I suggested, for placement in the try block :
> >
> > > >
> > > > Properties p = new Properties();
> > > > p.load( vProperties );
> > > > p.setProperty(Runtime.FILE_RESOURCE_LOADER_PATH, vTemplates);
> > > > p.setProperty(Runtime.RUNTIME_LOG, vLog);
> > > > Runtime.init();
> > >
> > > There is no velocity properties file.
> >
> > Well, you are setting a set of properties in the first line in the try
> > block - but I know that - you depend upon the velocity defaults.
>
> The velocity properties file is empty, that line will go away.
> Take a look at an example turbine app and you will see that.
How does it go away? That line is in the source code of the
TurbineVelocityService.
> What you are looking at will become
>
> Runtime.setResourceProperty(Runtime.FILE_RESOURCE_LOADER_PATH, path)
> Runtime.setProperty(Runtime.RUNTIME_LOG, log)
> Runtime.init()
>
> I think this is the simplest, most reliable way to embed velocity. I don't
> need to create an object to initialize. And for each other path I just
> add another line like the first. How much easier could it get?
Well, it could be
Runtime.setAdditionalResourceProperty( ....)
...
...
and then we can have Properties compatible tokens.
And doesn't the whole thing go away if you switch to jar'd templates and
the ClasspathResourceLoader for easy deployment in servlet containers?
It becomes :
Runtime.setProperty( Runtime.RUNTIME_LOG, log);
Runtime.init();
or
Properties p = new Properties()
p.setProperty( Runtime.RUNTIME_LOG, log);
Runtime.init( p );
and we could dump the whole Runtime.setProperty() /
setResourceProperty() machinery?
> >
> >
> > But yes, I see that it wouldn't work as suggested, because of the
> > dependence upon the default properties, so the first setProperty()
> > wouldn't do the right thing, as FILE_RESOURCE_LOADER_PATH isn't a real
> > property.
>
> Of course it's a real property? Shall we make people look up what the
> property is for the log file? In order to set it's value?
No - it's not a 'real property', it's a magic cookie of sorts. It's
value is 'file.resource.path'
Could I really drop that into a properties file? I don't think so - it
depends upon the special code in setResourceProperty() to deal with it.
The log file makes sense, as it isn't something dynamic nor dependent
upon a property value. We define our log property to be 'runtime.log',
and that's fixed.
The FILE_RESOURCE_LOADER_PATH depends upon the *value* of the 'real
property' resource.loader.N.public.name, I think.
Isn't that how it works?
> > You could keep the Turbine code the same, change the resource path
> > property to include the trailing integer, and people could still use
> > Properties.
>
> So something like this:
>
> Runtime.setResourceProperty(SOME_CONSTANT + ".1", path1)
>
> Here we are protected against changes in the defaults, but looks
> terrible compared to the method that will be used.
See above.
> or aere you suggesting:
>
> Runtime.setResourceProperty("resource.loader.1.resource.path.1", path1)
>
> which is just plain dangerous because the defaults may change. using
> free text to set a runtime property is not a good idea.
"dangerous because the defaults may change" ?
Turbine is 100% dependant upon the defaults not changing, and further,
will break if we decide to change the value of a string constant.
> >
> >
> >
> > > >
> > > >
> > > > It's one line of code more than the current implementation. It's
> > > > structurally the same : the current implementation just uses Runtime as
> > > > a Properties, and the above uses a Properties as a Properties.
> > >
> > > So why create another object if you don't have to?
> >
> > If we only accepted a Configuration object, wouldn't everyone have to
> > create a new Configuration object and load it from their Properties?
> > And we are talking init() time anyway...
>
> They would use it exactly as a properties file. I don't see
> the problem.
I know. <sigh> :)
> >
> >
> > > >
> > > >
> > > > Of course, there may be something subtle about Turbine where that
> > > > wouldn't work. I am not sure.
> > > >
> > > > If we got rid of those methods from Runtime, Runtime would get smaller,
> > > > and clean up the initialization semantics w/o undue burden on Turbine.
> > > > Further, in general one wouldn't be tempted to call
> > > > Runtime.setProperty() after init(), since those methods wouldn't exist.
> > >
> > > But we very well may want to in the future.
> >
> > I agree.
> >
> > > >
> > > >
> > > > The rule would be 1) optionally setup the properties (in a Properties
> > > > or Configuration) and then 2) call init() [with no arg for defaults,
> > > > with a filename for vel to read, with a Properties if you have one, or a
> > > > Configuration if you use that.]
> > > >
> > > > And I don't consider either the 'standard way' - I just see the
> > > > java.util.Properties as an easy way using a standard class that people
> > > > could already use in their own applications (like Turbine seems to) - so
> > > > they could just glom together the velocity properties with their
> > > > properties for easy configuration, and just use that.
> > > >
> > > > I think giving people the choice of
> > > >
> > > > init() : use defaults
> > > > init( filename ) : use filename
> > > > init( Properties ) :
> > > > init( Configuration );
> > >
> > > >
> > > > would make it more convenient.
> > >
> > > If the init(Props) is removed before we release then people won't
> > > know what they're missing. I would say deprecate the use of
> > > init(Props) to give people fair warning.
> >
> > All I am saying is that we don't have to - we could work it out, or I
> > believe we could and am willing to help, try to get this to work where
> > we *can* support init(Props).
> >
> > Is there any other downside other than the current bit regarding
> > multi-path, which I believe we can fix?
>
> I will not accept using free text for setting runtime properties, that
> is my objection.
Re 'free text' if you mean letting people put arbitrary strings into
things, I agree. But the constants are dangerous too - the best may be
a real configuration API.
> And I think we feel differently about the status
> of loaders. I feel that the file loader and the class loader deserve
> to be first class, they are core to velocity and providing constants
> for their use provides the best way to embed velocity.
No, I agree about first-class status, only because they would/will be
the most popular. I think that the constants are dangerous though... a
real API might be the way to do this.
> I don't need a properties file, but in order to accommodate them
> I would have to use a method initialization that I think is dangerous
> i.e. using free text to set the resource paths. That's the only way
> I see your way working. If you use a constant then your back
> doing what is already done. I think the constant is good and
> I think the idea of standard class loaders is good.
great. so we seem to agree on everything - if I can make Turbine happy,
not use 'free text', eliminate the 'Hail Mary' constant approach, have
Properties compatible multi-path properties, then all is well?
> I don't think making people use a Configuration class
> is really a big deal. If we can't get this sorted out before
> tomorrow night then we can just remove from the todo
> and concentrate on the other items for release.
We will have to fix something either way.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [Proposal] Velocity Release Plan 1.0
Posted by Jason van Zyl <jv...@periapt.com>.
"Geir Magnusson Jr." wrote:
> Jason van Zyl wrote:
> >
> > "Geir Magnusson Jr." wrote:
> >
> > > [SNIP]
> > > Can we just support both then? The 'same value key' problem is somewhat
> > > artificial, because you and john wanted to do, for multiple paths,
> > >
> > > path = foo
> > > path = bar
> > > path = woogie
> >
> > Which is equivalent to
> > path = foo,bar,woogie
> >
> > With the Configuration class, and we wanted it because we use
> > that in turbine and the classes have been used for a long time and
> > work.
>
> > >
> > >
> > > rather than
> > >
> > > path = foo:bar:woogie
> > >
> > > or
> > >
> > > path.1 = foo
> > > path.2 = bar
> > > path.3 = woogie
> > >
> > > (The latter way is nicer - you don't have to worry that the separator
> > > is a valid character in the data )
> >
> > This will not work. The name of the property has to be the same in
> > order to dynamically set the resource path. In Turbine we might
> > do:
>
> Sorry. Of course I meant :
>
> resource.loader.1.resource.path.1 = foo
> resource.loader.1.resource.path.2 = bar
>
> (just too lazy to type it)
>
> > 1)
> > Runtime.setSourceProperty(FILE_RESOURCE_PATH, path1);
> > Runtime.setSourceProperty(FILE_RESOURCE_PATH, path2);
> >
> > I do not want to have to do
> >
> > 1)
> > Runtime.setProperty("resource.loader.1.file.resource.path.1", path1);
> > Runtime.setProperty("resource.loader.1.file.resource.path.2", path1);
> >
> > I don't have a safe constant to work with, and the file loader might not be
> > the first loader. If the defaults for the file resource loader get overriden
> > then this code will break. 1) is always guaranteed to work.
>
> I still think that we should punt on these methods to Runtime since a
> single call to init() can do all of this, and I think that hardwiring
> FILE_RESOURCE_PATH as a constant isn't a good idea as it isn't safe
> because it makes assumptions about the public.name of the loader...but
> ignoring that, what do these really have to do with each other?
We agreed that the file resource loader was a standard loader did we not?
And as a standard loader the setting of its configuration can be set
as it is done above. I think the class resource loader should be a standard
loader too. With these two, I think 99% of most cases are handled.
>
>
> FILE_LOADER_RESOURCE_PATH isn't defined as
> "resource.loader.1.file.resource.path". It is "file.resource.path",
> which isn't a real property for configuring a loader. This is a
> source-specific mechanism dependant upon the ResourceManager taking it
> apart to deduce the public name of the loader. The other part
> 'resource.path' is passed into the Configuration object handling that
> loader, and it does the right thing, tacking it on the end. I do like
> this hack, and the Configuration class seems rather nice, BTW.
I don't consider it a hack, I think it provides the easiest way to
embed velocity. No external velocity props is required, you
have access to the standard loaders and you can set the
config for the loader very easily using the constant.
>
>
> But, that said, making the props
>
> resource.loader.1.resource.path.1 = foo
> resource.loader.1.resource.path.2 = bar
>
> would have no effect on that. It would require a change in loading the
> Configuration to deal with the trailing integer, bit you already are
> dealing with the complexity of the multiple resource loader definitions
> and ordering.
Yes it would have an effect. Turbine doesn't have a velocity properties
file and depends on the the defaults that velocity provides. Now for
Turbine I'm on top of the changes but with your method I would have
to the
Runtime.setProperties("resource.loader.1.resource.path.1", path1)
But this requires people to dig through the source and find out
what the defaults are to get the property right. Why should I
have to know what that string is? I just want to set a resource
path.
And if we decided to change the defaults, people who didn't stay
on top of changes would find their apps broken.
So let me get this clear, apps that have no velocity properties
are supposed use
Runtime.setProperties("resource.loader.1.resource.path.1", path1)
to set a resource path?
>
>
> What I am saying is that changing the multi-path property to be as I
> suggest would have *no* effect on the way Turbine prefers to load
> things, or those Runtime methods in general. They wouldn't have to
> change at all. The only thing that would change is how the
> Configuration / Configurations / ExtendedProperties deals with the new
> property spec.
If I'm correct in how I think you want to specify a resource path
then it certainly has an effect. But clarify this if I misunderstand.
>
>
> >
> > >
> > >
> > > If we switched to the second way, then both the Configuration and the
> > > Properties would work. I do agree that it's a shame there isn't
> > > multi-valued property support in Properties.
> >
> > No, they wouldn't.
>
> I think they could.
>
> > >
> > >
> > > > > The multi-key problem only surfaced recently with the multi-node
> > > > > template and jar paths, and that was solvable in the same way WM solved
> > > > > it, by letting the property be free form, and letting the entity that
> > > > > required multi-valued properties to parse in the way it needs.
> > > >
> > > > The Configuration class always dealt with multiple keys correctly, it's the
> > > > Properties
> > > > class that doesn't. It should have been something like init(Configuration) from
> > > > the start. But it didn't even cross my mind at the time, I just think this is
> > > > the correct way to go and is used the same way a Properties class is so it's
> > > > not like there's a big learning curve or anything :-)
> > >
> > > It's not the learning curve : I just don't want to force people to use
> > > it. I am just arguing to keep it, and add an init( Configuration ), but
> > > keeping init( Properties ) would be easy for those using the Properties
> > > in their own apps.
> >
> > That's why I want to do the change now before we launch. Get
> > rid of it now while we can!
>
> I just don't think we need to force everyone to use an entirely new
> class (for everyone except Turbine - and currently, Turbine doesn't use
> it to init Velocity, and the Velocity version isn't the same as the
> Turbine version) to handle application-level properties specification
> methods, since I believe (and am happy to prove) that we could easily
> acommodate both.
We're not forcing people to do anything, we haven't even released?
Sure you could accomdate it with free text definition of properties
but I don't think that's a good thing. I think the constant is a much
safer mechanism. Users of velocity will use the file loader that we
provide and I think the way turbine uses velocity is the most
convenient.
How about we poll the users? I think the way turbine does it is easiest,
you use properties. How about we ask the users?
>
>
> I just don't see the downside - I think we can get everything we want at
> once - arrange things so that we support what I suppose lots of Java
> programmers (including the person who wrote TurbineVelocityService) use
> for application configuration... java.util.Properties.
If I have to use free text definition of properties then I definitely
have a problem with it.
>
>
> > > > >
> > > > > Everything that we want to do could be achieved with the
> > > > > java.util.Properties.
> > > >
> > > > I don't think so, the Properties class doesn't behave the way the
> > > > Configuration class does and it's the Configuration class that has
> > > > always been the core configuration class. To make a Properties
> > > > class work with the Configuration class you would have to add
> > > > a hack in the runtime to parse CSV lines when the Configuration
> > > > class does this already.
> > >
> > > Or if we made a simple change to what a multi-path spec is, to
> > >
> > > path.1 = foo
> > > path.2 = bar
> > >
> > > wouldn't the issue just go away?
> >
> > No, as explained above.
>
> I wasn't convinced - see above.
>
> > >
> > >
> > > > > If Configuration makes life easier internally to
> > > > > justify the added code, then I am all for it, but I still think that we
> > > > > should support the standard Properties object as a full functional
> > > > > method of init.
> > > >
> > > > Just for the record, I don't consider the using a Properties object to
> > > > init the runtime the standard way. The app that has been using Velocity
> > > > the longest, turbine, has never used this method.
> > >
> > > And looking at TurbineVelocityService, it uses a Properties internally
> > > (so some apps *do* use the Properties class for configuration
> > > management), and knows where its properties file is. I think the
> > > following code would make Turbine compatible with using j.u.Properties
> > > to initialize :
> >
> > It doesn't work the way you think it does.
>
> Ok. I figured that I messed it up somewhere - The current Turbine code
> is :
>
> /*
> * Get the properties for this Service
> */
> Properties props = getProperties();
>
> String vProperties = TurbineServlet.getRealPath(
> props.getProperty("properties", null));
>
> String vLog = TurbineServlet.getRealPath(
> props.getProperty("log", null));
>
> String vTemplates = TurbineServlet.getRealPath(
> props.getProperty("templates", null));
>
> [SNIPPING UNRELATED CODE FOR BREVITY]
>
> try
> {
> Runtime.setProperties(vProperties);
> Runtime.setSourceProperty(Runtime.FILE_RESOURCE_LOADER_PATH,
> vTemplates);
> Runtime.setProperty(Runtime.RUNTIME_LOG, vLog);
> Runtime.init();
> encoding = Runtime.getString(Runtime.TEMPLATE_ENCODING);
> Log.info("VelocityService: encoding=" + encoding);
> }
> catch(Exception e)
> ...
>
> And I suggested, for placement in the try block :
>
> > >
> > > Properties p = new Properties();
> > > p.load( vProperties );
> > > p.setProperty(Runtime.FILE_RESOURCE_LOADER_PATH, vTemplates);
> > > p.setProperty(Runtime.RUNTIME_LOG, vLog);
> > > Runtime.init();
> >
> > There is no velocity properties file.
>
> Well, you are setting a set of properties in the first line in the try
> block - but I know that - you depend upon the velocity defaults.
The velocity properties file is empty, that line will go away.
Take a look at an example turbine app and you will see that.
What you are looking at will become
Runtime.setResourceProperty(Runtime.FILE_RESOURCE_LOADER_PATH, path)
Runtime.setProperty(Runtime.RUNTIME_LOG, log)
Runtime.init()
I think this is the simplest, most reliable way to embed velocity. I don't
need to create an object to initialize. And for each other path I just
add another line like the first. How much easier could it get?
>
>
> But yes, I see that it wouldn't work as suggested, because of the
> dependence upon the default properties, so the first setProperty()
> wouldn't do the right thing, as FILE_RESOURCE_LOADER_PATH isn't a real
> property.
Of course it's a real property? Shall we make people look up what the
property is for the log file? In order to set it's value?
> You could keep the Turbine code the same, change the resource path
> property to include the trailing integer, and people could still use
> Properties.
So something like this:
Runtime.setResourceProperty(SOME_CONSTANT + ".1", path1)
Here we are protected against changes in the defaults, but looks
terrible compared to the method that will be used.
or are you suggesting:
Runtime.setResourceProperty("resource.loader.1.resource.path.1", path1)
which is just plain dangerous because the defaults may change. using
free text to set a runtime property is not a good idea.
>
>
>
> > >
> > >
> > > It's one line of code more than the current implementation. It's
> > > structurally the same : the current implementation just uses Runtime as
> > > a Properties, and the above uses a Properties as a Properties.
> >
> > So why create another object if you don't have to?
>
> If we only accepted a Configuration object, wouldn't everyone have to
> create a new Configuration object and load it from their Properties?
> And we are talking init() time anyway...
They would use it exactly as a properties file. I don't see
the problem.
>
>
> > >
> > >
> > > Of course, there may be something subtle about Turbine where that
> > > wouldn't work. I am not sure.
> > >
> > > If we got rid of those methods from Runtime, Runtime would get smaller,
> > > and clean up the initialization semantics w/o undue burden on Turbine.
> > > Further, in general one wouldn't be tempted to call
> > > Runtime.setProperty() after init(), since those methods wouldn't exist.
> >
> > But we very well may want to in the future.
>
> I agree.
>
> > >
> > >
> > > The rule would be 1) optionally setup the properties (in a Properties
> > > or Configuration) and then 2) call init() [with no arg for defaults,
> > > with a filename for vel to read, with a Properties if you have one, or a
> > > Configuration if you use that.]
> > >
> > > And I don't consider either the 'standard way' - I just see the
> > > java.util.Properties as an easy way using a standard class that people
> > > could already use in their own applications (like Turbine seems to) - so
> > > they could just glom together the velocity properties with their
> > > properties for easy configuration, and just use that.
> > >
> > > I think giving people the choice of
> > >
> > > init() : use defaults
> > > init( filename ) : use filename
> > > init( Properties ) :
> > > init( Configuration );
> >
> > >
> > > would make it more convenient.
> >
> > If the init(Props) is removed before we release then people won't
> > know what they're missing. I would say deprecate the use of
> > init(Props) to give people fair warning.
>
> All I am saying is that we don't have to - we could work it out, or I
> believe we could and am willing to help, try to get this to work where
> we *can* support init(Props).
>
> Is there any other downside other than the current bit regarding
> multi-path, which I believe we can fix?
I will not accept using free text for setting runtime properties, that
is my objection. And I think we feel differently about the status
of loaders. I feel that the file loader and the class loader deserve
to be first class, they are core to velocity and providing constants
for their use provides the best way to embed velocity.
I don't need a properties file, but in order to accommodate them
I would have to use a method initialization that I think is dangerous
i.e. using free text to set the resource paths. That's the only way
I see your way working. If you use a constant then your back
doing what is already done. I think the constant is good and
I think the idea of standard class loaders is good.
I don't think making people use a Configuration class
is really a big deal. If we can't get this sorted out before
tomorrow night then we can just remove from the todo
and concentrate on the other items for release.
>
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
Re: [Proposal] Velocity Release Plan 1.0
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jason van Zyl wrote:
>
> "Geir Magnusson Jr." wrote:
>
> > [SNIP]
> > Can we just support both then? The 'same value key' problem is somewhat
> > artificial, because you and john wanted to do, for multiple paths,
> >
> > path = foo
> > path = bar
> > path = woogie
>
> Which is equivalent to
> path = foo,bar,woogie
>
> With the Configuration class, and we wanted it because we use
> that in turbine and the classes have been used for a long time and
> work.
Ah. I looked in turbine, and didn't see that. Did see a Properties
though.
> >
> >
> > rather than
> >
> > path = foo:bar:woogie
> >
> > or
> >
> > path.1 = foo
> > path.2 = bar
> > path.3 = woogie
> >
> > (The latter way is nicer - you don't have to worry that the separator
> > is a valid character in the data )
>
> This will not work. The name of the property has to be the same in
> order to dynamically set the resource path. In Turbine we might
> do:
Sorry. Of course I meant :
resource.loader.1.resource.path.1 = foo
resource.loader.1.resource.path.2 = bar
(just too lazy to type it)
> 1)
> Runtime.setSourceProperty(FILE_RESOURCE_PATH, path1);
> Runtime.setSourceProperty(FILE_RESOURCE_PATH, path2);
>
> I do not want to have to do
>
> 1)
> Runtime.setProperty("resource.loader.1.file.resource.path.1", path1);
> Runtime.setProperty("resource.loader.1.file.resource.path.2", path1);
>
> I don't have a safe constant to work with, and the file loader might not be
> the first loader. If the defaults for the file resource loader get overriden
> then this code will break. 1) is always guaranteed to work.
I still think that we should punt on these methods to Runtime since a
single call to init() can do all of this, and I think that hardwiring
FILE_RESOURCE_PATH as a constant isn't a good idea as it isn't safe
because it makes assumptions about the public.name of the loader...but
ignoring that, what do these really have to do with each other?
FILE_LOADER_RESOURCE_PATH isn't defined as
"resource.loader.1.file.resource.path". It is "file.resource.path",
which isn't a real property for configuring a loader. This is a
source-specific mechanism dependant upon the ResourceManager taking it
apart to deduce the public name of the loader. The other part
'resource.path' is passed into the Configuration object handling that
loader, and it does the right thing, tacking it on the end. I do like
this hack, and the Configuration class seems rather nice, BTW.
But, that said, making the props
resource.loader.1.resource.path.1 = foo
resource.loader.1.resource.path.2 = bar
would have no effect on that. It would require a change in loading the
Configuration to deal with the trailing integer, bit you already are
dealing with the complexity of the multiple resource loader definitions
and ordering.
What I am saying is that changing the multi-path property to be as I
suggest would have *no* effect on the way Turbine prefers to load
things, or those Runtime methods in general. They wouldn't have to
change at all. The only thing that would change is how the
Configuration / Configurations / ExtendedProperties deals with the new
property spec.
>
> >
> >
> > If we switched to the second way, then both the Configuration and the
> > Properties would work. I do agree that it's a shame there isn't
> > multi-valued property support in Properties.
>
> No, they wouldn't.
I think they could.
> >
> >
> > > > The multi-key problem only surfaced recently with the multi-node
> > > > template and jar paths, and that was solvable in the same way WM solved
> > > > it, by letting the property be free form, and letting the entity that
> > > > required multi-valued properties to parse in the way it needs.
> > >
> > > The Configuration class always dealt with multiple keys correctly, it's the
> > > Properties
> > > class that doesn't. It should have been something like init(Configuration) from
> > > the start. But it didn't even cross my mind at the time, I just think this is
> > > the correct way to go and is used the same way a Properties class is so it's
> > > not like there's a big learning curve or anything :-)
> >
> > It's not the learning curve : I just don't want to force people to use
> > it. I am just arguing to keep it, and add an init( Configuration ), but
> > keeping init( Properties ) would be easy for those using the Properties
> > in their own apps.
>
> That's why I want to do the change now before we launch. Get
> rid of it now while we can!
I just don't think we need to force everyone to use an entirely new
class (for everyone except Turbine - and currently, Turbine doesn't use
it to init Velocity, and the Velocity version isn't the same as the
Turbine version) to handle application-level properties specification
methods, since I believe (and am happy to prove) that we could easily
acommodate both.
I just don't see the downside - I think we can get everything we want at
once - arrange things so that we support what I suppose lots of Java
programmers (including the person who wrote TurbineVelocityService) use
for application configuration... java.util.Properties.
> > > >
> > > > Everything that we want to do could be achieved with the
> > > > java.util.Properties.
> > >
> > > I don't think so, the Properties class doesn't behave the way the
> > > Configuration class does and it's the Configuration class that has
> > > always been the core configuration class. To make a Properties
> > > class work with the Configuration class you would have to add
> > > a hack in the runtime to parse CSV lines when the Configuration
> > > class does this already.
> >
> > Or if we made a simple change to what a multi-path spec is, to
> >
> > path.1 = foo
> > path.2 = bar
> >
> > wouldn't the issue just go away?
>
> No, as explained above.
I wasn't convinced - see above.
> >
> >
> > > > If Configuration makes life easier internally to
> > > > justify the added code, then I am all for it, but I still think that we
> > > > should support the standard Properties object as a full functional
> > > > method of init.
> > >
> > > Just for the record, I don't consider the using a Properties object to
> > > init the runtime the standard way. The app that has been using Velocity
> > > the longest, turbine, has never used this method.
> >
> > And looking at TurbineVelocityService, it uses a Properties internally
> > (so some apps *do* use the Properties class for configuration
> > management), and knows where its properties file is. I think the
> > following code would make Turbine compatible with using j.u.Properties
> > to initialize :
>
> It doesn't work the way you think it does.
Ok. I figured that I messed it up somewhere - The current Turbine code
is :
/*
* Get the properties for this Service
*/
Properties props = getProperties();
String vProperties = TurbineServlet.getRealPath(
props.getProperty("properties", null));
String vLog = TurbineServlet.getRealPath(
props.getProperty("log", null));
String vTemplates = TurbineServlet.getRealPath(
props.getProperty("templates", null));
[SNIPPING UNRELATED CODE FOR BREVITY]
try
{
Runtime.setProperties(vProperties);
Runtime.setSourceProperty(Runtime.FILE_RESOURCE_LOADER_PATH,
vTemplates);
Runtime.setProperty(Runtime.RUNTIME_LOG, vLog);
Runtime.init();
encoding = Runtime.getString(Runtime.TEMPLATE_ENCODING);
Log.info("VelocityService: encoding=" + encoding);
}
catch(Exception e)
...
And I suggested, for placement in the try block :
> >
> > Properties p = new Properties();
> > p.load( vProperties );
> > p.setProperty(Runtime.FILE_RESOURCE_LOADER_PATH, vTemplates);
> > p.setProperty(Runtime.RUNTIME_LOG, vLog);
> > Runtime.init();
>
> There is no velocity properties file.
Well, you are setting a set of properties in the first line in the try
block - but I know that - you depend upon the velocity defaults.
But yes, I see that it wouldn't work as suggested, because of the
dependence upon the default properties, so the first setProperty()
wouldn't do the right thing, as FILE_RESOURCE_LOADER_PATH isn't a real
property.
One thing you could do is change the ResourceManager to handle the magic
cookies like FILE_RESOURCE_LOADER_PATH and deal with them as it does
now, but there is not point getting into that here.
You could keep the Turbine code the same, change the resource path
property to include the trailing integer, and people could still use
Properties.
> >
> >
> > It's one line of code more than the current implementation. It's
> > structurally the same : the current implementation just uses Runtime as
> > a Properties, and the above uses a Properties as a Properties.
>
> So why create another object if you don't have to?
If we only accepted a Configuration object, wouldn't everyone have to
create a new Configuration object and load it from their Properties?
And we are talking init() time anyway...
> >
> >
> > Of course, there may be something subtle about Turbine where that
> > wouldn't work. I am not sure.
> >
> > If we got rid of those methods from Runtime, Runtime would get smaller,
> > and clean up the initialization semantics w/o undue burden on Turbine.
> > Further, in general one wouldn't be tempted to call
> > Runtime.setProperty() after init(), since those methods wouldn't exist.
>
> But we very well may want to in the future.
I agree.
> >
> >
> > Currently, we don't support post-init() property additions anyway, so
> > nothing would be lost.
>
> But we would be losing the potential ability to configure the system
> while it's running. Say add a new template path, drop in some new
> templates and away you go. As part of a content management system
> that can't be shut down for re-configuration. Lots of possibilities
> there. If anything I say get rid of the init(Props) if we're really
> looking to clean things up.
But they wouldn't work anyway now : the loaders are all set up and
initted...
I agree it's a good thing and we want to do it - but we would have to
fix a few things for it to work.
> >
> >
> > The rule would be 1) optionally setup the properties (in a Properties
> > or Configuration) and then 2) call init() [with no arg for defaults,
> > with a filename for vel to read, with a Properties if you have one, or a
> > Configuration if you use that.]
> >
> > And I don't consider either the 'standard way' - I just see the
> > java.util.Properties as an easy way using a standard class that people
> > could already use in their own applications (like Turbine seems to) - so
> > they could just glom together the velocity properties with their
> > properties for easy configuration, and just use that.
> >
> > I think giving people the choice of
> >
> > init() : use defaults
> > init( filename ) : use filename
> > init( Properties ) :
> > init( Configuration );
>
> >
> > would make it more convenient.
>
> If the init(Props) is removed before we release then people won't
> know what they're missing. I would say deprecate the use of
> init(Props) to give people fair warning.
All I am saying is that we don't have to - we could work it out, or I
believe we could and am willing to help, try to get this to work where
we *can* support init(Props).
Is there any other downside other than the current bit regarding
multi-path, which I believe we can fix?
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [Proposal] Velocity Release Plan 1.0
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> another reason to get rid of Properties:
>
> If we move to an XML based configuration, we will need a way to do that
> anyway and you can't map a Properties object to all of the different forms
> of XML configuration that are possible. We could make the Configuration
> object an interface and then have PropertiesConfiguration and
> XMLConfiguration implementations.
Hm. Can see another discussion coming :)
I am not suggesting that we don't use the Configuration. It's a nice
bit of code.
What I am trying to convince y'all of is that Properties seem to be a
common way for people to deal with configuration information that isn't
deeply structured, and ours isn't.
So the summary is this : because (I think) that we can structure
(without heavy lifting) our properties such that both Properties and
Configurations will work, we should do it. I don't want to FORCE people
to use a Configuration object to work with Velocity, as they may already
have existing Properties in their apps. We aren't adding anything that
is confusing them - because they already know how to deal with
Properties.
At worst, our init(Properties) simply digs out the data and places in a
Configuration.
When our configuration is best structured in XML, then we do that,
although I would still think that we will be able to get away with
regular properties for quite a while...
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [Proposal] Velocity Release Plan 1.0
Posted by Jon Stevens <jo...@latchkey.com>.
another reason to get rid of Properties:
If we move to an XML based configuration, we will need a way to do that
anyway and you can't map a Properties object to all of the different forms
of XML configuration that are possible. We could make the Configuration
object an interface and then have PropertiesConfiguration and
XMLConfiguration implementations.
-jon
Re: [Proposal] Velocity Release Plan 1.0
Posted by Jason van Zyl <jv...@periapt.com>.
"Geir Magnusson Jr." wrote:
> Jason van Zyl wrote:
> >
> > Yo,
> >
> > Comments in mixed in.
> >
> > "Geir Magnusson Jr." wrote:
> >
> > > I think that we really should consider this decision carefully. I
> > > really like having the options of using the Properties to load - since I
> > > would bet that the Properties class is very common for people to use in
> > > their own apps, every java101 programmer understands how to use it, etc,
> > > etc, etc
> >
> > There would be no difference in usage. And we used the Configuration type
> > class before we started doing anything with Properties. We should have
> > considered carefully using Properties but we didn't: we should have used
> > the same type config class for initializing the Runtime that the Runtime
> > uses internally . It has only become an issue now because we have
> > multiple same value keys, but the Configuration class has always
> > been able to deal with this.
>
> Can we just support both then? The 'same value key' problem is somewhat
> artificial, because you and john wanted to do, for multiple paths,
>
> path = foo
> path = bar
> path = woogie
Which is equivalent to
path = foo,bar,woogie
With the Configuration class, and we wanted it because we use
that in turbine and the classes have been used for a long time and
work.
>
>
> rather than
>
> path = foo:bar:woogie
>
> or
>
> path.1 = foo
> path.2 = bar
> path.3 = woogie
>
> (The latter way is nicer - you don't have to worry that the separator
> is a valid character in the data )
This will not work. The name of the property has to be the same in
order to dynamically set the resource path. In Turbine we might
do:
1)
Runtime.setSourceProperty(FILE_RESOURCE_PATH, path1);
Runtime.setSourceProperty(FILE_RESOURCE_PATH, path2);
I do not want to have to do
1)
Runtime.setProperty("resource.loader.1.file.resource.path.1", path1);
Runtime.setProperty("resource.loader.1.file.resource.path.2", path1);
I don't have a safe constant to work with, and the file loader might not be
the first loader. If the defaults for the file resource loader get overriden
then this code will break. 1) is always guaranteed to work.
The
path.1 = foo
path.2 = bar
path.3 = yuck
is not a good idea.
>
>
> If we switched to the second way, then both the Configuration and the
> Properties would work. I do agree that it's a shame there isn't
> multi-valued property support in Properties.
No, they wouldn't.
>
>
> > > The multi-key problem only surfaced recently with the multi-node
> > > template and jar paths, and that was solvable in the same way WM solved
> > > it, by letting the property be free form, and letting the entity that
> > > required multi-valued properties to parse in the way it needs.
> >
> > The Configuration class always dealt with multiple keys correctly, it's the
> > Properties
> > class that doesn't. It should have been something like init(Configuration) from
> > the start. But it didn't even cross my mind at the time, I just think this is
> > the correct way to go and is used the same way a Properties class is so it's
> > not like there's a big learning curve or anything :-)
>
> It's not the learning curve : I just don't want to force people to use
> it. I am just arguing to keep it, and add an init( Configuration ), but
> keeping init( Properties ) would be easy for those using the Properties
> in their own apps.
That's why I want to do the change now before we launch. Get
rid of it now while we can!
>
>
> > >
> > >
> > > Everything that we want to do could be achieved with the
> > > java.util.Properties.
> >
> > I don't think so, the Properties class doesn't behave the way the
> > Configuration class does and it's the Configuration class that has
> > always been the core configuration class. To make a Properties
> > class work with the Configuration class you would have to add
> > a hack in the runtime to parse CSV lines when the Configuration
> > class does this already.
>
> Or if we made a simple change to what a multi-path spec is, to
>
> path.1 = foo
> path.2 = bar
>
> wouldn't the issue just go away?
No, as explained above.
>
>
> > > If Configuration makes life easier internally to
> > > justify the added code, then I am all for it, but I still think that we
> > > should support the standard Properties object as a full functional
> > > method of init.
> >
> > Just for the record, I don't consider the using a Properties object to
> > init the runtime the standard way. The app that has been using Velocity
> > the longest, turbine, has never used this method.
>
> And looking at TurbineVelocityService, it uses a Properties internally
> (so some apps *do* use the Properties class for configuration
> management), and knows where its properties file is. I think the
> following code would make Turbine compatible with using j.u.Properties
> to initialize :
It doesn't work the way you think it does.
>
>
> Properties p = new Properties();
> p.load( vProperties );
> p.setProperty(Runtime.FILE_RESOURCE_LOADER_PATH, vTemplates);
> p.setProperty(Runtime.RUNTIME_LOG, vLog);
> Runtime.init();
There is no velocity properties file.
>
>
> It's one line of code more than the current implementation. It's
> structurally the same : the current implementation just uses Runtime as
> a Properties, and the above uses a Properties as a Properties.
So why create another object if you don't have to?
>
>
> Of course, there may be something subtle about Turbine where that
> wouldn't work. I am not sure.
>
> If we got rid of those methods from Runtime, Runtime would get smaller,
> and clean up the initialization semantics w/o undue burden on Turbine.
> Further, in general one wouldn't be tempted to call
> Runtime.setProperty() after init(), since those methods wouldn't exist.
But we very well may want to in the future.
>
>
> Currently, we don't support post-init() property additions anyway, so
> nothing would be lost.
But we would be losing the potential ability to configure the system
while it's running. Say add a new template path, drop in some new
templates and away you go. As part of a content management system
that can't be shut down for re-configuration. Lots of possibilities
there. If anything I say get rid of the init(Props) if we're really
looking to clean things up.
>
>
> The rule would be 1) optionally setup the properties (in a Properties
> or Configuration) and then 2) call init() [with no arg for defaults,
> with a filename for vel to read, with a Properties if you have one, or a
> Configuration if you use that.]
>
> And I don't consider either the 'standard way' - I just see the
> java.util.Properties as an easy way using a standard class that people
> could already use in their own applications (like Turbine seems to) - so
> they could just glom together the velocity properties with their
> properties for easy configuration, and just use that.
>
> I think giving people the choice of
>
> init() : use defaults
> init( filename ) : use filename
> init( Properties ) :
> init( Configuration );
>
> would make it more convenient.
If the init(Props) is removed before we release then people won't
know what they're missing. I would say deprecate the use of
init(Props) to give people fair warning.
>
>
> > My argument is that the usage is the same, initializing with a Configuration
> > class is more consistent with what we've always had , which is the
> > Configuration type class (I think it was a mistake we never caught or thought
> > of),
> > and it will simplify the Runtime internally. The Resource Loader was greatly
> > simplied by just using the Configuration.subset(prefix) to grab the config for
> > a resource loader. And laying over top of defaults will be easier with the
> > Configuration class. You can simply do something like
>
> <mental meandering aside>
> I wonder if it would get even simpler if you let the consuming class
> (the *ResourceLoader) deal with their own configuration properties, and
> let the Manager get what it needs either directly from the
> configuration, or in the case of values specific to each loader,
> through a standard manager interface supported by each Loader. A simple
> set of utilities to help the loaders would make it easy.
> </mental meandering aside>
>
>
> > Configuration c = new Configuration(config File/Stream, defaults File/Stream)
> >
> > and it will take care of all our current behaviour regarding the loading of
> > a default set of properties and laying down overriding properties on top
> > of them.
>
> Cool. I guess to summarize, I am just trying to say that we can support
> all of the types, I think, if we just change the new multi-value
> property bit to something else.
>
> like
>
> resource.loader.1.resource.path.1 = foo
> resource.loader.1.resource.path.2 = bar
> resource.loader.1.resource.path.3 = woogie
As I've said this won't work.
>
>
> it would also mean that the user could specify the search order
> explicitly. (I guess they do it implicily with the ordering now ?)
>
> >
> > > The set-what-you-want-and-call-init method is quite simple....
> >
> > Yes. I agree
> >
> > Configuration c = new Configuration()
> > c.setProperty(a,b)
> >
> > Properties p = new Properties()
> > p.setProperty(a,b)
> >
> > If they work the same, is it really that much of a leap?
>
> Not at all. I didn't think it would be. :)
>
> But if I alrady have a Properties for my app, I can just drop it in.
Yes, but you can change it now. It's not like we have _that_ many
users (I hope we have a lot, but I think I'm dreaming at this stage).
Get rid of init(props) while we can.
What if we called Configuration -> SmartProperties/ExtendedProperties
to make it more familiar?
>
>
> > > > o Log4j: I would like to swtich to using log4j as it seems to be the most
> > > > mature of the logging packages and the options provided by log4j
> > > > are very desirable IMO. Rolling log files, or logging to a database (to
> > > > go along with the data resource loader :-)), or logging via syslog. All
> > > > these things are possible for minimal effort as log4j will do all the
> > > > work :-)
> > >
> > > can it be pluggable?
> >
> > Do we really need it to be pluggable? I think log4j will become the standard
> > logging tool. But if it's decided that it should be pluggable then what do we
> > go for? Turbine has a pluggable logging service, Avalon has one, and there's
> > the Sun Logging API (whatever it's called).
> >
> > My preference would be to just use log4j.
>
> me too as our default.
>
> but if there was a simple wrapper we could put around log4j, we have the
> ability to easily change later, or if a user already has some existing
> investment in a logging system they lik, they could wrap it in our
> interface and plug velocity right in.
I would like to switch over to using log4j and do the interface
stuff later. I don't think it's necessary so I would do the switch
and if someone wants to make an interface or when the logging
API is final we can adhere to that.
>
>
> > >
> > > > o Get a copy of Alexandria running on the apache.org box so that we
> > > > can have a link on our site to the javadocs. We can do this manually
> > > > if necessary, but it would be nice to use Alexandria as that's what
> > > > it's intended for. Hopefully Jeff Martin and Sam Ruby can help out
> > > > with this so we will have Javadocs updated daily by the time we
> > > > release.
> > >
> > > Can we update javadocs whenever we want with that?
> >
> > I'm hoping it does it daily by itself. That's what I'm lead to
> > believe anyway :-) I want it to do it by itself. Like magic!
>
> Ah magic.
>
> What I was asking was - can I force it if I need to, or do you have to
> wait for the next cycle? Just thinking if we need a quick update for
> some reason. Doesn't matter : sounds good.
>
>
> > --
> > jvz.
> >
> > Jason van Zyl
> > jvanzyl@periapt.com
> >
> > http://jakarta.apache.org/velocity
> > http://jakarta.apache.org/turbine
>
> --
> Geir Magnusson Jr. geirm@optonline.com
> Developing for the web? See http://jakarta.apache.org/velocity/
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
Re: [Proposal] Velocity Release Plan 1.0
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Daniel Rall wrote:
>
> jeff <jl...@houseofdistraction.com> writes:
>
> > How about whoever wants to use Properties: make an adapter that converts a
> > Properties to a Configuration, add it to the contrib directory and then be
> > done with this discussion.
> >
> > Or something.
>
> Heh. The adapter would be a ctor on Configurations.
or just init(Properties) :)
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [Proposal] Velocity Release Plan 1.0
Posted by Daniel Rall <dl...@collab.net>.
jeff <jl...@houseofdistraction.com> writes:
> How about whoever wants to use Properties: make an adapter that converts a
> Properties to a Configuration, add it to the contrib directory and then be
> done with this discussion.
>
> Or something.
Heh. The adapter would be a ctor on Configurations.
--
Daniel Rall <dl...@collab.net>
Re: [Proposal] Velocity Release Plan 1.0
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
jeff wrote:
>
> How about whoever wants to use Properties: make an adapter that converts a
> Properties to a Configuration, add it to the contrib directory and then be
> done with this discussion.
It's not that simple. The problems come in because the new multi-path
properties were defined (this weekend) such that you *can't* use a
Properties. Other than that, we have supported Properties for
initialization since late November.
All I am arguing is that we can slightly alter the muli-path properties
to work with a Properties object.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [Proposal] Velocity Release Plan 1.0
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Paulo Gaspar wrote:
>
> IMO, this is the closest to the correct solution.
>
> For me, the correct way to do it is to have a separate configuration
> mechanism. Just build an interface somewhere (Runtime?) to set configuration
> values (properties) and get whatever configurator that suits your needs.
That inverts the problem, at least the one I am thinking about. The
question is not to *make* a configurator, but to keep the properties
such that a Properties can be used to configure the Velocity runtime.
> For the sake of ease-of-use, Runtime should use a default configuration
> mechanism to initialize itself on first use - if no other initialization was
> performed before. This default mechanism could just be the Properties based
> one that is now used, so that the current behaviour is not changed.
Actually, it does have a default configuration, and even easier than
what you suggest - the default configuration is simply a call to init()
- Velocity will use a set of default properties included in the jar. No
muss, no fuss.
>
> If this default Properties configurator is loaded "by name", people that
> prefer XML-configurators or whatever-configurators don't even need to have
> the default configurator present.
The way it works now is you get to choose among :
- Runtime.init() : uses builtin defaults
- Runtime.init( filename ) : uses the built-in defaults, and overlays
them with any properties from the file
- Runtime.init( Properties ) : uses built-in defaultas, and overlays
them with any properties from the Properties.
Since we now have the handy-dandy Configuration class, we can add
- Runtime.init( Configuration ) : uses built-in defaults, and overlyas
them with any properties from the Configuration.
> This also allows for easier programatic onfiguration directly from Servlet
> code using some application specific stuff.
>
> So, as usual, I prefer having a default behaviour and the option to plug
> alternative ones.
Right. I think of it as conventional behavior and support for alternate
ones.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
RE: [Proposal] Velocity Release Plan 1.0
Posted by Paulo Gaspar <pa...@krankikom.de>.
IMO, this is the closest to the correct solution.
For me, the correct way to do it is to have a separate configuration
mechanism. Just build an interface somewhere (Runtime?) to set configuration
values (properties) and get whatever configurator that suits your needs.
For the sake of ease-of-use, Runtime should use a default configuration
mechanism to initialize itself on first use - if no other initialization was
performed before. This default mechanism could just be the Properties based
one that is now used, so that the current behaviour is not changed.
If this default Properties configurator is loaded "by name", people that
prefer XML-configurators or whatever-configurators don't even need to have
the default configurator present.
This also allows for easier programatic onfiguration directly from Servlet
code using some application specific stuff.
So, as usual, I prefer having a default behaviour and the option to plug
alternative ones.
Have fun,
Paulo
PS: I still owe some patches. They are not forgotten and I will build them.
> -----Original Message-----
> From: jeff [mailto:jlb@houseofdistraction.com]
> Sent: Tuesday, March 06, 2001 06:44
> To: velocity-dev@jakarta.apache.org
> Subject: Re: [Proposal] Velocity Release Plan 1.0
>
>
> How about whoever wants to use Properties: make an adapter that converts a
> Properties to a Configuration, add it to the contrib directory and then be
> done with this discussion.
>
> Or something.
>
>
>
Re: [Proposal] Velocity Release Plan 1.0
Posted by jeff <jl...@houseofdistraction.com>.
How about whoever wants to use Properties: make an adapter that converts a
Properties to a Configuration, add it to the contrib directory and then be
done with this discussion.
Or something.
Re: [Proposal] Velocity Release Plan 1.0
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jason van Zyl wrote:
>
> Yo,
>
> Comments in mixed in.
>
> "Geir Magnusson Jr." wrote:
>
> > I think that we really should consider this decision carefully. I
> > really like having the options of using the Properties to load - since I
> > would bet that the Properties class is very common for people to use in
> > their own apps, every java101 programmer understands how to use it, etc,
> > etc, etc
>
> There would be no difference in usage. And we used the Configuration type
> class before we started doing anything with Properties. We should have
> considered carefully using Properties but we didn't: we should have used
> the same type config class for initializing the Runtime that the Runtime
> uses internally . It has only become an issue now because we have
> multiple same value keys, but the Configuration class has always
> been able to deal with this.
Can we just support both then? The 'same value key' problem is somewhat
artificial, because you and john wanted to do, for multiple paths,
path = foo
path = bar
path = woogie
rather than
path = foo:bar:woogie
or
path.1 = foo
path.2 = bar
path.3 = woogie
(The latter way is nicer - you don't have to worry that the separator
is a valid character in the data )
If we switched to the second way, then both the Configuration and the
Properties would work. I do agree that it's a shame there isn't
multi-valued property support in Properties.
> > The multi-key problem only surfaced recently with the multi-node
> > template and jar paths, and that was solvable in the same way WM solved
> > it, by letting the property be free form, and letting the entity that
> > required multi-valued properties to parse in the way it needs.
>
> The Configuration class always dealt with multiple keys correctly, it's the
> Properties
> class that doesn't. It should have been something like init(Configuration) from
> the start. But it didn't even cross my mind at the time, I just think this is
> the correct way to go and is used the same way a Properties class is so it's
> not like there's a big learning curve or anything :-)
It's not the learning curve : I just don't want to force people to use
it. I am just arguing to keep it, and add an init( Configuration ), but
keeping init( Properties ) would be easy for those using the Properties
in their own apps.
> >
> >
> > Everything that we want to do could be achieved with the
> > java.util.Properties.
>
> I don't think so, the Properties class doesn't behave the way the
> Configuration class does and it's the Configuration class that has
> always been the core configuration class. To make a Properties
> class work with the Configuration class you would have to add
> a hack in the runtime to parse CSV lines when the Configuration
> class does this already.
Or if we made a simple change to what a multi-path spec is, to
path.1 = foo
path.2 = bar
wouldn't the issue just go away?
> > If Configuration makes life easier internally to
> > justify the added code, then I am all for it, but I still think that we
> > should support the standard Properties object as a full functional
> > method of init.
>
> Just for the record, I don't consider the using a Properties object to
> init the runtime the standard way. The app that has been using Velocity
> the longest, turbine, has never used this method.
And looking at TurbineVelocityService, it uses a Properties internally
(so some apps *do* use the Properties class for configuration
management), and knows where its properties file is. I think the
following code would make Turbine compatible with using j.u.Properties
to initialize :
Properties p = new Properties();
p.load( vProperties );
p.setProperty(Runtime.FILE_RESOURCE_LOADER_PATH, vTemplates);
p.setProperty(Runtime.RUNTIME_LOG, vLog);
Runtime.init();
It's one line of code more than the current implementation. It's
structurally the same : the current implementation just uses Runtime as
a Properties, and the above uses a Properties as a Properties.
Of course, there may be something subtle about Turbine where that
wouldn't work. I am not sure.
If we got rid of those methods from Runtime, Runtime would get smaller,
and clean up the initialization semantics w/o undue burden on Turbine.
Further, in general one wouldn't be tempted to call
Runtime.setProperty() after init(), since those methods wouldn't exist.
Currently, we don't support post-init() property additions anyway, so
nothing would be lost.
The rule would be 1) optionally setup the properties (in a Properties
or Configuration) and then 2) call init() [with no arg for defaults,
with a filename for vel to read, with a Properties if you have one, or a
Configuration if you use that.]
And I don't consider either the 'standard way' - I just see the
java.util.Properties as an easy way using a standard class that people
could already use in their own applications (like Turbine seems to) - so
they could just glom together the velocity properties with their
properties for easy configuration, and just use that.
I think giving people the choice of
init() : use defaults
init( filename ) : use filename
init( Properties ) :
init( Configuration )
would make it more convenient.
> My argument is that the usage is the same, initializing with a Configuration
> class is more consistent with what we've always had , which is the
> Configuration type class (I think it was a mistake we never caught or thought
> of),
> and it will simplify the Runtime internally. The Resource Loader was greatly
> simplied by just using the Configuration.subset(prefix) to grab the config for
> a resource loader. And laying over top of defaults will be easier with the
> Configuration class. You can simply do something like
<mental meandering aside>
I wonder if it would get even simpler if you let the consuming class
(the *ResourceLoader) deal with their own configuration properties, and
let the Manager get what it needs either directly from the
configuration, or in the case of values specific to each loader,
through a standard manager interface supported by each Loader. A simple
set of utilities to help the loaders would make it easy.
</mental meandering aside>
> Configuration c = new Configuration(config File/Stream, defaults File/Stream)
>
> and it will take care of all our current behaviour regarding the loading of
> a default set of properties and laying down overriding properties on top
> of them.
Cool. I guess to summarize, I am just trying to say that we can support
all of the types, I think, if we just change the new multi-value
property bit to something else.
like
resource.loader.1.resource.path.1 = foo
resource.loader.1.resource.path.2 = bar
resource.loader.1.resource.path.3 = woogie
it would also mean that the user could specify the search order
explicitly. (I guess they do it implicily with the ordering now ?)
>
> > The set-what-you-want-and-call-init method is quite simple....
>
> Yes. I agree
>
> Configuration c = new Configuration()
> c.setProperty(a,b)
>
> Properties p = new Properties()
> p.setProperty(a,b)
>
> If they work the same, is it really that much of a leap?
Not at all. I didn't think it would be. :)
But if I alrady have a Properties for my app, I can just drop it in.
> > > o Log4j: I would like to swtich to using log4j as it seems to be the most
> > > mature of the logging packages and the options provided by log4j
> > > are very desirable IMO. Rolling log files, or logging to a database (to
> > > go along with the data resource loader :-)), or logging via syslog. All
> > > these things are possible for minimal effort as log4j will do all the
> > > work :-)
> >
> > can it be pluggable?
>
> Do we really need it to be pluggable? I think log4j will become the standard
> logging tool. But if it's decided that it should be pluggable then what do we
> go for? Turbine has a pluggable logging service, Avalon has one, and there's
> the Sun Logging API (whatever it's called).
>
> My preference would be to just use log4j.
me too as our default.
but if there was a simple wrapper we could put around log4j, we have the
ability to easily change later, or if a user already has some existing
investment in a logging system they lik, they could wrap it in our
interface and plug velocity right in.
> >
> > > o Get a copy of Alexandria running on the apache.org box so that we
> > > can have a link on our site to the javadocs. We can do this manually
> > > if necessary, but it would be nice to use Alexandria as that's what
> > > it's intended for. Hopefully Jeff Martin and Sam Ruby can help out
> > > with this so we will have Javadocs updated daily by the time we
> > > release.
> >
> > Can we update javadocs whenever we want with that?
>
> I'm hoping it does it daily by itself. That's what I'm lead to
> believe anyway :-) I want it to do it by itself. Like magic!
Ah magic.
What I was asking was - can I force it if I need to, or do you have to
wait for the next cycle? Just thinking if we need a quick update for
some reason. Doesn't matter : sounds good.
> > I'll dig up a bunch.
> >
>
> Cool.
>
> --
> jvz.
>
> Jason van Zyl
> jvanzyl@periapt.com
>
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/turbine
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [Proposal] Velocity Release Plan 1.0
Posted by Jason van Zyl <jv...@periapt.com>.
Daniel Rall wrote:
> Jason van Zyl <jv...@periapt.com> writes:
> > If they work the same, is it really that much of a leap?
>
> No, it's not a leap at all. But zero learning curve is always the
> best kind. ;)
I'd say it's pretty much zero. I'm totally for ease of use, and we
can still use Properties if it's really seen as necessary. I just don't
want to put a parsing hack in the Runtime when the Configuration
class does it all.
>
>
> I don't feel strongly about it either way, just like the simplicity of
> using a standard Java library class. Consistancy has as much--if not
> more--value, however.
> --
I think using the configuration class makes things more consistent,
and we can name the class SmartProperties/ExtendedProperties
to keep things at a familiar level.
>
>
> Daniel Rall <dl...@collab.net>
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
Re: [Proposal] Velocity Release Plan 1.0
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> on 3/5/01 6:08 PM, "Daniel Rall" <dl...@collab.net> wrote:
>
> > I don't feel strongly about it either way, just like the simplicity of
> > using a standard Java library class. Consistancy has as much--if not
> > more--value, however.
>
> Except for the fact that it doesn't do what we need.
>
> Configuration does the exact same thing as Properties except that it works.
>
> This isn't real hard guys.
Except we are setting it up for the Properties not to work. They would
work fine if we switched from:
....
path = foo
path = bar
path = woogie
....
to
path.1 = foo
path.2 = bar
path.3 = woogie
right?
We already use this in grouping loader properties into sets, so its
nothing terribly new or different.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [Proposal] Velocity Release Plan 1.0
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/5/01 6:08 PM, "Daniel Rall" <dl...@collab.net> wrote:
> I don't feel strongly about it either way, just like the simplicity of
> using a standard Java library class. Consistancy has as much--if not
> more--value, however.
Except for the fact that it doesn't do what we need.
Configuration does the exact same thing as Properties except that it works.
This isn't real hard guys.
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
Re: [Proposal] Velocity Release Plan 1.0
Posted by Daniel Rall <dl...@collab.net>.
Jason van Zyl <jv...@periapt.com> writes:
> If they work the same, is it really that much of a leap?
No, it's not a leap at all. But zero learning curve is always the
best kind. ;)
I don't feel strongly about it either way, just like the simplicity of
using a standard Java library class. Consistancy has as much--if not
more--value, however.
--
Daniel Rall <dl...@collab.net>
Re: [Proposal] Velocity Release Plan 1.0
Posted by Jason van Zyl <jv...@periapt.com>.
Yo,
Comments in mixed in.
"Geir Magnusson Jr." wrote:
>
> >
> > o Configuration cleanup: I would like to use the Configuration class instead
> > of
> > Properties as it deals with multiple same name keys, includes, and deals
> > with
> > default values internally. This would clean up the Runtime, and all
> > configuration
> > issues will be handled by the Configuration class. The Configuration
> > class is
> > an amalgum of the
> > VelocityResources/ExtendedProperties/ConfigurationRepository.
> > The attempt was to make it work like a standard Properties class except
> > it has
> > more features.
>
> I think that we really should consider this decision carefully. I
> really like having the options of using the Properties to load - since I
> would bet that the Properties class is very common for people to use in
> their own apps, every java101 programmer understands how to use it, etc,
> etc, etc
There would be no difference in usage. And we used the Configuration type
class before we started doing anything with Properties. We should have
considered carefully using Properties but we didn't: we should have used
the same type config class for initializing the Runtime that the Runtime
uses internally . It has only become an issue now because we have
multiple same value keys, but the Configuration class has always
been able to deal with this.
>
>
> The multi-key problem only surfaced recently with the multi-node
> template and jar paths, and that was solvable in the same way WM solved
> it, by letting the property be free form, and letting the entity that
> required multi-valued properties to parse in the way it needs.
The Configuration class always dealt with multiple keys correctly, it's the
Properties
class that doesn't. It should have been something like init(Configuration) from
the start. But it didn't even cross my mind at the time, I just think this is
the correct way to go and is used the same way a Properties class is so it's
not like there's a big learning curve or anything :-)
>
>
> Everything that we want to do could be achieved with the
> java.util.Properties.
I don't think so, the Properties class doesn't behave the way the
Configuration class does and it's the Configuration class that has
always been the core configuration class. To make a Properties
class work with the Configuration class you would have to add
a hack in the runtime to parse CSV lines when the Configuration
class does this already.
> If Configuration makes life easier internally to
> justify the added code, then I am all for it, but I still think that we
> should support the standard Properties object as a full functional
> method of init.
Just for the record, I don't consider the using a Properties object to
init the runtime the standard way. The app that has been using Velocity
the longest, turbine, has never used this method.
My argument is that the usage is the same, initializing with a Configuration
class is more consistent with what we've always had , which is the
Configuration type class (I think it was a mistake we never caught or thought
of),
and it will simplify the Runtime internally. The Resource Loader was greatly
simplied by just using the Configuration.subset(prefix) to grab the config for
a resource loader. And laying over top of defaults will be easier with the
Configuration class. You can simply do something like
Configuration c = new Configuration(config File/Stream, defaults File/Stream)
and it will take care of all our current behaviour regarding the loading of
a default set of properties and laying down overriding properties on top
of them.
>
>
> The set-what-you-want-and-call-init method is quite simple....
Yes. I agree
Configuration c = new Configuration()
c.setProperty(a,b)
Properties p = new Properties()
p.setProperty(a,b)
If they work the same, is it really that much of a leap?
>
>
> > o Log4j: I would like to swtich to using log4j as it seems to be the most
> > mature of the logging packages and the options provided by log4j
> > are very desirable IMO. Rolling log files, or logging to a database (to
> > go along with the data resource loader :-)), or logging via syslog. All
> > these things are possible for minimal effort as log4j will do all the
> > work :-)
>
> can it be pluggable?
Do we really need it to be pluggable? I think log4j will become the standard
logging tool. But if it's decided that it should be pluggable then what do we
go for? Turbine has a pluggable logging service, Avalon has one, and there's
the Sun Logging API (whatever it's called).
My preference would be to just use log4j.
>
>
> > o Get a copy of Alexandria running on the apache.org box so that we
> > can have a link on our site to the javadocs. We can do this manually
> > if necessary, but it would be nice to use Alexandria as that's what
> > it's intended for. Hopefully Jeff Martin and Sam Ruby can help out
> > with this so we will have Javadocs updated daily by the time we
> > release.
>
> Can we update javadocs whenever we want with that?
I'm hoping it does it daily by itself. That's what I'm lead to
believe anyway :-) I want it to do it by itself. Like magic!
> I'll dig up a bunch.
>
Cool.
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
Re: [Proposal] Velocity Release Plan 1.0
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jason van Zyl wrote:
>
> Jon Stevens wrote:
>
> > on 3/5/01 3:26 PM, "Jason van Zyl" <jv...@periapt.com> wrote:
> >
> > > We should decide what should be done befor this date: the two
> > > things that I would like to do code wise are clean up the configuration
> > > code and start using log4j. After that bug fixes and documentation.
> >
> > Update the TODO page then. :-)
>
> I'll start the list to get us rolling then ...
>
> o Configuration cleanup: I would like to use the Configuration class instead
> of
> Properties as it deals with multiple same name keys, includes, and deals
> with
> default values internally. This would clean up the Runtime, and all
> configuration
> issues will be handled by the Configuration class. The Configuration
> class is
> an amalgum of the
> VelocityResources/ExtendedProperties/ConfigurationRepository.
> The attempt was to make it work like a standard Properties class except
> it has
> more features.
I think that we really should consider this decision carefully. I
really like having the options of using the Properties to load - since I
would bet that the Properties class is very common for people to use in
their own apps, every java101 programmer understands how to use it, etc,
etc, etc
The multi-key problem only surfaced recently with the multi-node
template and jar paths, and that was solvable in the same way WM solved
it, by letting the property be free form, and letting the entity that
required multi-valued properties to parse in the way it needs.
Everything that we want to do could be achieved with the
java.util.Properties. If Configuration makes life easier internally to
justify the added code, then I am all for it, but I still think that we
should support the standard Properties object as a full functional
method of init.
The set-what-you-want-and-call-init method is quite simple....
> o Log4j: I would like to swtich to using log4j as it seems to be the most
> mature of the logging packages and the options provided by log4j
> are very desirable IMO. Rolling log files, or logging to a database (to
> go along with the data resource loader :-)), or logging via syslog. All
> these things are possible for minimal effort as log4j will do all the
> work :-)
can it be pluggable?
> o Get a copy of Alexandria running on the apache.org box so that we
> can have a link on our site to the javadocs. We can do this manually
> if necessary, but it would be nice to use Alexandria as that's what
> it's intended for. Hopefully Jeff Martin and Sam Ruby can help out
> with this so we will have Javadocs updated daily by the time we
> release.
Can we update javadocs whenever we want with that?
> o UML Diagrams: Even if they are quick it would be nice to have. I
> have asked a Turbiner (Ilkka Priha) if he could reverse engineer a
> set of diagrams like he did for Turbine.
>
> o Getting a mailing list archive working, or at least have a link
> to mail-archive.com at the bottom of the messages going out
> on the list.
>
> That's what I can think of off the top of my head. Just add what
> you feel is necessary and I will produce a todo from it
>
I'll dig up a bunch.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [Proposal] Velocity Release Plan 1.0
Posted by Jason van Zyl <jv...@periapt.com>.
Jon Stevens wrote:
> on 3/5/01 3:26 PM, "Jason van Zyl" <jv...@periapt.com> wrote:
>
> > We should decide what should be done befor this date: the two
> > things that I would like to do code wise are clean up the configuration
> > code and start using log4j. After that bug fixes and documentation.
>
> Update the TODO page then. :-)
I'll start the list to get us rolling then ...
o Configuration cleanup: I would like to use the Configuration class instead
of
Properties as it deals with multiple same name keys, includes, and deals
with
default values internally. This would clean up the Runtime, and all
configuration
issues will be handled by the Configuration class. The Configuration
class is
an amalgum of the
VelocityResources/ExtendedProperties/ConfigurationRepository.
The attempt was to make it work like a standard Properties class except
it has
more features.
o Log4j: I would like to swtich to using log4j as it seems to be the most
mature of the logging packages and the options provided by log4j
are very desirable IMO. Rolling log files, or logging to a database (to
go along with the data resource loader :-)), or logging via syslog. All
these things are possible for minimal effort as log4j will do all the
work :-)
o Get a copy of Alexandria running on the apache.org box so that we
can have a link on our site to the javadocs. We can do this manually
if necessary, but it would be nice to use Alexandria as that's what
it's intended for. Hopefully Jeff Martin and Sam Ruby can help out
with this so we will have Javadocs updated daily by the time we
release.
o UML Diagrams: Even if they are quick it would be nice to have. I
have asked a Turbiner (Ilkka Priha) if he could reverse engineer a
set of diagrams like he did for Turbine.
o Getting a mailing list archive working, or at least have a link
to mail-archive.com at the bottom of the messages going out
on the list.
That's what I can think of off the top of my head. Just add what
you feel is necessary and I will produce a todo from it
>
>
> -jon
>
> --
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
> <http://jakarta.apache.org/velocity/ymtd/ymtd.html>
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
Re: [Proposal] Velocity Release Plan 1.0
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> on 3/5/01 3:53 PM, "Jason van Zyl" <jv...@periapt.com> wrote:
>
> > So I would like to fix the config stuff, and I would like to do the switch
> > to log4j but I wanted to get some agreement before I add items to
> > the 1.0 release todo.
>
> works for me.
>
> i think that we should also go through and test the build process and
> release process because last night i had to fix a few things to get
> forumdemo working as well as some of the documentation for it. the other
> demo stuff probably has similar problems.
>
I just redid the examples recently.
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [Proposal] Velocity Release Plan 1.0
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/5/01 3:53 PM, "Jason van Zyl" <jv...@periapt.com> wrote:
> So I would like to fix the config stuff, and I would like to do the switch
> to log4j but I wanted to get some agreement before I add items to
> the 1.0 release todo.
works for me.
i think that we should also go through and test the build process and
release process because last night i had to fix a few things to get
forumdemo working as well as some of the documentation for it. the other
demo stuff probably has similar problems.
thanks,
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
Re: [Proposal] Velocity Release Plan 1.0
Posted by Jason van Zyl <jv...@periapt.com>.
Jon Stevens wrote:
> on 3/5/01 3:26 PM, "Jason van Zyl" <jv...@periapt.com> wrote:
>
> > We should decide what should be done befor this date: the two
> > things that I would like to do code wise are clean up the configuration
> > code and start using log4j. After that bug fixes and documentation.
>
> Update the TODO page then. :-)
Sure, I just wanted to get a feel for what other felt would be good
for the 1.0 then make a formal "for 1.0 todo". The we have something
to stick to for the release.
So I would like to fix the config stuff, and I would like to do the switch
to log4j but I wanted to get some agreement before I add items to
the 1.0 release todo.
>
>
> -jon
>
> --
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
> <http://jakarta.apache.org/velocity/ymtd/ymtd.html>
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
Re: [Proposal] Velocity Release Plan 1.0
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/5/01 3:26 PM, "Jason van Zyl" <jv...@periapt.com> wrote:
> We should decide what should be done befor this date: the two
> things that I would like to do code wise are clean up the configuration
> code and start using log4j. After that bug fixes and documentation.
Update the TODO page then. :-)
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
Re: [Proposal] Velocity Release Plan 1.0
Posted by Jason van Zyl <jv...@periapt.com>.
Jon Stevens wrote:
> Hey all,
>
> Velocity is doing extremely well. The code is working well and a number of
> us are relying on it for our projects. Therefore, I propose that we start
> working towards a release plan for a 1.0 version. We will have two beta's a
> week apart and a final release.
>
> Here is the goals:
>
> Velocity 1.0b1 - Monday, March 18th, 2001
We should decide what should be done befor this date: the two
things that I would like to do code wise are clean up the configuration
code and start using log4j. After that bug fixes and documentation.
>
>
> This version will be our first official release. It will include all of
> the current code to date. The core code will be declared stable and
> after 1.0b1, there will only be bug fixes and no more feature additions
> util the next major release.
>
> Velocity 1.0b2 - Monday, March 26th, 2001
>
> Any bugs that have been found between b1 and the next week will be
> fixed and a new release will occur. In this release, people should
> report that all bugs from the previous release have been confirmed as
> fixed.
>
> Velocity 1.0 - Monday, April 2nd, 2001
>
> Velocity 1.0 release.
>
> The voting period will end at midnight on Tuesday March 6th, 2001. I will
> post the vote tally later that day.
>
> <----- Please return this portion with your vote ----->
> [ X] +1 I am in favor of this plan and will help
> [ ] +0 I am in favor of this plan, but am unable to help
> [ ] -0 I am not in favor of this plan
> [ ] -1 I am against this plan being executed, and my
> reason is:
> <----------------------------------------------------->
>
> For approval, there must be at least three +1 votes by Committers,
> and more +1 votes than -1 votes.
>
> thanks,
>
> -jon
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
Re: [Proposal] Velocity Release Plan 1.0
Posted by Dave Bryson <da...@miceda-data.com>.
On Mon, 05 Mar 2001, you wrote:
> <----- Please return this portion with your vote ----->
> [X] +1 I am in favor of this plan and will help
> [ ] +0 I am in favor of this plan, but am unable to help
> [ ] -0 I am not in favor of this plan
> [ ] -1 I am against this plan being executed, and my
> reason is:
> <----------------------------------------------------->
--
Dave Bryson
daveb@miceda-data.com
----------------------
Re: [Proposal] Velocity Release Plan 1.0
Posted by Daniel Rall <dl...@collab.net>.
Jon Stevens <jo...@latchkey.com> writes:
> <----- Please return this portion with your vote ----->
> [ ] +1 I am in favor of this plan and will help
> [X] +0 I am in favor of this plan, but am unable to help
> [ ] -0 I am not in favor of this plan
> [ ] -1 I am against this plan being executed, and my
Things are still too busy at work to promise my time, but I may be
able to help a little during the latter milestones if tasks are
clearly defined enough.
--
Daniel Rall <dl...@collab.net>
Re: [Proposal] Velocity Release Plan 1.0
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Christoph Reck wrote:
> I intend to put up a my application as a demo of a VTL configured
> controller, and velocity generated views. But I need to get a site
> for hosting it and permission to do so.
I might have some space available... what does it do?
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [Proposal] Velocity Release Plan 1.0
Posted by Christoph Reck <Ch...@dlr.de>.
> <----- Please return this portion with your vote ----->
> [ ] +1 I am in favor of this plan and will help
> [X] +0 I am in favor of this plan, but am unable to help
> [ ] -0 I am not in favor of this plan
> [ ] -1 I am against this plan being executed, and my
> reason is:
> <----------------------------------------------------->
I've moved to another task. My velocity project is closed, in
april I will do an update.
Note that I'm still hoping that the quiet reference for a set directive
finds its way in. Here three examples where I need it:
#set( $cache = $!session.getAttribute("applicationCache") )
## start a new cache if not yet defined...
...
#set( $state = $!guideExportStatus.put("state", "locked") )##set the lock
## test the $state if it was already locked...
...
#set( $taskXML = $!Xml.applyXPath($services, $xpathSpec).get(0) )
## now do something if the task was not defined...
In all of these three cases, a null return value is feasible, but
an error message in the log is undesireable.
I intend to put up a my application as a demo of a VTL configured
controller, and velocity generated views. But I need to get a site
for hosting it and permission to do so.
:) Chirstoph
Re: [Proposal] Velocity Release Plan 1.0
Posted by Josh Lucas <jo...@stonecottage.com>.
Jon Stevens wrote:
>
>
> <----- Please return this portion with your vote ----->
> [ ] +1 I am in favor of this plan and will help
> [x] +0 I am in favor of this plan, but am unable to help
> [ ] -0 I am not in favor of this plan
> [ ] -1 I am against this plan being executed, and my
> reason is:
> <----------------------------------------------------->
As with dlr, I can't promise that I'll be able to help but I can test as
well as help with any release-specific issues.
josh