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/02/04 20:18:57 UTC
Case
Ok,
Here is a reason to *not* allow Geir's recent case "feature" into the
introspection...
Page 40 of Sun's JMX Spec PDF ("jmx_instr_agent.pdf"):
"Case Sensitivity
All attribute and operation names derived from these design patterns are
case-sensitive. For example, this means that the methods getstate and
setState define two attributes, one called state that is read-only, and one
called State that is write-only. While case sensitivity applies directly to
component names of standard MBeans, it is also applicable to all component
names of all types of MBeans, standard or dynamic. In general, all names of
classes, attributes, operations, methods, and internal elements defined in
the JMX specification are case sensitive, whether they appear as data or as
functional code when they are manipulated by management operations."
Comments?
-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/> | <http://java.apache.org/turbine/>
Re: Case
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> Ok,
>
> Here is a reason to *not* allow Geir's recent case "feature" into the
> introspection...
I am not sure that there is a 'reason' in there. I can't figure out
what it's saying :)
This actually may support ('may', because it isn't clear what exactly
your JMX snippet is trying to say...) what I was saying about our
inverted interpretation of the bean spec, namely that the bean spec
directly addresses the notion of finding a pair of methods, getFoo and
setFoo, and therefore concluding that there is a property 'foo', by
making the statement that when you have a property 'Foo', it should be
cased according to rules in sec 8.9 (or near there), namely Foo -> foo
In Velocity, we do the inverse, finding a property-like reference in a
template like $foo.bar and then go flailing about to find something that
matches, namely getbar() or getBar()
One gets the sense, when confronted with the bean spec (which leaves
things wide open, IMO) and the JMX spec, that someone isn't minding the
store :)
As for comments on the snippet you included, I am confused :
If the snippet said something like "this means that the methods getstate
and getState define two attributes, state and State...." but I already
can infer that getstate() gives me something readable, and setState() is
something writeable.
I guess I find that snipped below somewhat difficult to understand,
actually, and if not in actual conflict with the bean spec, certainly
adding confusion.
As to the applicability to Velocity, I think we have to find out more.
If common practice is going towards something horrible like encouraging
people writing classes/interfaces that have methods getstate() and
getState(), then we have a problem. [And I think the problem isn't in
velocity, but Java coding standards overall :) ]
We can also just have a switch to turn off anything but 'explicit
introspection'.
geir
>
> Page 40 of Sun's JMX Spec PDF ("jmx_instr_agent.pdf"):
>
> "Case Sensitivity
>
> All attribute and operation names derived from these design patterns are
> case-sensitive. For example, this means that the methods getstate and
> setState define two attributes, one called state that is read-only, and one
> called State that is write-only. While case sensitivity applies directly to
> component names of standard MBeans, it is also applicable to all component
> names of all types of MBeans, standard or dynamic. In general, all names of
> classes, attributes, operations, methods, and internal elements defined in
> the JMX specification are case sensitive, whether they appear as data or as
> functional code when they are manipulated by management operations."
>
> Comments?
>
> -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/> | <http://java.apache.org/turbine/>
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
RE: Case - plugable discovery proposal
Posted by Paulo Gaspar <pa...@krankikom.de>.
> -----Original Message-----
> From: gmj@optonline.net [mailto:gmj@optonline.net]On Behalf Of Geir
> Magnusson Jr.
>
> Paulo Gaspar wrote:
> ...
>
> > Maybe the best I can do is to provide a JDBC sample.
>
> It can be a working class, not just a sample.
> ...
Ok, I will use something that just accepts a ResultSet and a column
name/number as input. That leaves for the user to take care of all
the application stuff and eases detecting what type of column is
there and reading its data.
I'll be back with this,
Paulo
Re: Case - plugable discovery proposal
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Paulo Gaspar wrote:
>
> I think you are right about pushing it to the application level.
> This is the kind of thing that can have too many use cases.
That's my worry : that it will rapidly blossom into a hairball, whereas
lots of the things that are important, like connections, permissions,
etc are all something that have to be dealt with at the app layer.
> Maybe the best I can do is to provide a JDBC sample.
It can be a working class, not just a sample. I have always thought
that the resource management is an app issue, with all vel really
needing was an interface to take a String / InputStream / etc, but the
file stuff is *so* pervasive, including it makes sense. Of course, we
then got into issues dealing with things like the application root when
in a servlet container, and the question there was do we deal with this
in Velocity by providing a 'ServletTemplateLoader' or something that
knows about life in a servlet runner, or leave it to the app, providing
support maybe in VelocityServlet? I originally thought we should
provide a loader, but was eventually convinced that wasn't really the
right way to go. Turbine handles it just fine, for example, w/o extra
support (that will have to be maintained) in Velocity.
>
> Paulo
>
> > -----Original Message-----
> > From: gmj@optonline.net [mailto:gmj@optonline.net]On Behalf Of Geir
> > Magnusson Jr.
> >
> > Paulo Gaspar wrote:
> > >
> > > > Jason too care of that a while ago. A JDBC loader? :)
> > > >
> > > > geir
> > >
> > > Yeahp. I work a lot with JDBC and it would be easy for me.
> > > Feature sugestions?
> >
> > First, yeah, I think this would be useful for people. (Of course,
> > what's wrong with your filesystem ?)
> >
> > However (there had to be a however, right... :) I live in the "what can
> > be pushed to application layer should be pushed into application layer"
> > camp a lot of the time, and wonder if this would be a great tool for
> > applications.
> >
> > Something that would return a Template so you could use it in servlets
> > or in apps. That would then punt what could be ugly permissions /
> > config / setup / connection pooling / etc issues to the application
> > layer, where that stuff is usually handled already anyway.
> >
> > Thoughts?
> >
> > geir
> >
> >
> > --
> > Geir Magnusson Jr. geirm@optonline.com
> > Velocity : it's not just a good idea. It should be the law.
> > http://jakarta.apache.org/velocity
> >
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
RE: Case - plugable discovery proposal
Posted by Paulo Gaspar <pa...@krankikom.de>.
I think you are right about pushing it to the application level.
This is the kind of thing that can have too many use cases.
Maybe the best I can do is to provide a JDBC sample.
Paulo
> -----Original Message-----
> From: gmj@optonline.net [mailto:gmj@optonline.net]On Behalf Of Geir
> Magnusson Jr.
>
> Paulo Gaspar wrote:
> >
> > > Jason too care of that a while ago. A JDBC loader? :)
> > >
> > > geir
> >
> > Yeahp. I work a lot with JDBC and it would be easy for me.
> > Feature sugestions?
>
> First, yeah, I think this would be useful for people. (Of course,
> what's wrong with your filesystem ?)
>
> However (there had to be a however, right... :) I live in the "what can
> be pushed to application layer should be pushed into application layer"
> camp a lot of the time, and wonder if this would be a great tool for
> applications.
>
> Something that would return a Template so you could use it in servlets
> or in apps. That would then punt what could be ugly permissions /
> config / setup / connection pooling / etc issues to the application
> layer, where that stuff is usually handled already anyway.
>
> Thoughts?
>
> geir
>
>
> --
> Geir Magnusson Jr. geirm@optonline.com
> Velocity : it's not just a good idea. It should be the law.
> http://jakarta.apache.org/velocity
>
Re: Case - plugable discovery proposal
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Paulo Gaspar wrote:
>
> > Jason too care of that a while ago. A JDBC loader? :)
> >
> > geir
>
> Yeahp. I work a lot with JDBC and it would be easy for me.
> Feature sugestions?
First, yeah, I think this would be useful for people. (Of course,
what's wrong with your filesystem ?)
However (there had to be a however, right... :) I live in the "what can
be pushed to application layer should be pushed into application layer"
camp a lot of the time, and wonder if this would be a great tool for
applications.
Something that would return a Template so you could use it in servlets
or in apps. That would then punt what could be ugly permissions /
config / setup / connection pooling / etc issues to the application
layer, where that stuff is usually handled already anyway.
Thoughts?
geir
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
RE: Case - plugable discovery proposal
Posted by Paulo Gaspar <pa...@krankikom.de>.
> Jason too care of that a while ago. A JDBC loader? :)
>
> geir
Yeahp. I work a lot with JDBC and it would be easy for me.
Feature sugestions?
Paulo
Re: Case - plugable discovery proposal
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
I get the subject change. I forget jon's was 'Case'. Sorry. More
inline.
>
> By the way, is the loader unification issue still open? I have some interest
> on implementing that one too, including some simple JDBC support.
>
Jason too care of that a while ago. A JDBC loader? :)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
RE: Case - plugable discovery proposal
Posted by Paulo Gaspar <pa...@krankikom.de>.
> -----Original Message-----
> From: gmj@optonline.net [mailto:gmj@optonline.net]On Behalf Of Geir
> Magnusson Jr.
>
> Paulo Gaspar wrote:
> >
> > Geir,
> >
> > Took sometime to get back at this (an interesting movie on TV).
>
> Me too! I went to see "Crouching Tiger, Hidden Dragon." Great movie.
> Sorry to run off like that.
No problem. Then it also got late for me.
> > Ok, there is a single point for introspection call which is from:
> > ASTIdentifier.doIntrospection( Class data )
>
> We do it in a few other places as well. Yes, it might be good to bring
> those together into one place, but this is a very expensive aspect of
> Velocity's operation, so we need to be careful.
Sure, but I only found this point as a start to discovering properties.
I might be missing something but it was what I found using some searches.
Can you give me some pointers here?
> > Now, having:
> > public interface IntrospectionBuilder
> > { public AbstractExecutor doIntrospection( String identifier,
> Class data )
> > throws Exception;
> > }
> >
> > and an extra field for the Parser class like:
> > public final IntrospectionBuilder introBuilder;
>
> Why the Parser class? The parser has nothing to do with this - there is
> nothing static about this : a parsed template must be able to be used by
> multiple contexts at the same time. By this I mean nothing at parse
> time dictates the introspection information. My servlet using a parsed
> template can use an object with a method getFoo(), and your servlet
> using the same parsed template can use an object with a hashtable with
> "Foo" as a key, and if the template has $ob.Foo, we both are happy.
> This feature is one of the most powerful and beautiful, I think... :)
The parsed template would still be able to be used by multiple contexts at
the same time. The Parser is just a convenient holder for the reference to
the IntrospectionBuilder which avoids extra references. It also opens the
possibility of creating a parser that works with a different discovery rule
from the rest of the parsers... but I digress a bit here.
> > one could replace the introspection call (in ASTIdentifier.execute()):
> > executor = doIntrospection( c );
> > by
> > parser.introBuilder.doIntrospection( identifier, c );
>
> Sure. Still wondering about the parser bit though.
>
> > Profits:
> > The possibility of having plugable introspection, even per Parser.
>
> I see the benefit of pluggable introspection just for the modularity
> alone, although I wouldn't be thrilled about including in the vel
> distribution anything but a 'standard' introspection module, just for
> sanity's sake, and to avoid encouraging people from doing things like
> accessing things they shouldn't. 'public' and 'private' are there for a
> reason :) Of course, that would be up for a general vote, I guess.
Sure. I also think that only the standard introspection module should be
mounted. Anything else is a customization. At most one could provide a
sample for documentation purposes.
I already stated before: "The one thing that seems to make sense is to keep
Velocity with a standard discovery mechanism as much compatible as possible
to the beans standard, while allowing people to plug their own mechanism at
Run Time."
> > Costs:
> > - An extra member, and its initialization, for the Parser class. Since
> > a pool of such objects is used, this is a very low cost.
> > - A couple of extra references and an extra parameter to create the
> > introspection. This is not such high cost either.
>
> Yes, after thinking about it, there prollie wouldn't be much cost to it.
=:o)
> > Well, actually, maybe this costs less than keeping and initializing that
> > "method" field (in the ASTIdentifier class) that is not being used any
> > more.
> > =;o)
>
> Yes, that's just a leftover. Not sure how that relates here.
Doesn't. It was just something I found while researching this. Since it
really has some cost, I am mentioning it so that some one can remove it.
I do not pretend this is a justification for the plug in thing. That is why
I used the smiley. (Ok... maybe I had a bad choice of words.)
So, if you give me some pointers on the other starting points for
introspection that I am missing, I can code something as above and give it
back to you. Sample included.
Have fun,
Paulo
Re: Case - plugable discovery proposal
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Paulo Gaspar wrote:
>
> Geir,
>
> Took sometime to get back at this (an interesting movie on TV).
Me too! I went to see "Crouching Tiger, Hidden Dragon." Great movie.
Sorry to run off like that.
> Ok, there is a single point for introspection call which is from:
> ASTIdentifier.doIntrospection( Class data )
We do it in a few other places as well. Yes, it might be good to bring
those together into one place, but this is a very expensive aspect of
Velocity's operation, so we need to be careful.
> Now, having:
> public interface IntrospectionBuilder
> { public AbstractExecutor doIntrospection( String identifier, Class data )
> throws Exception;
> }
>
> and an extra field for the Parser class like:
> public final IntrospectionBuilder introBuilder;
Why the Parser class? The parser has nothing to do with this - there is
nothing static about this : a parsed template must be able to be used by
multiple contexts at the same time. By this I mean nothing at parse
time dictates the introspection information. My servlet using a parsed
template can use an object with a method getFoo(), and your servlet
using the same parsed template can use an object with a hashtable with
"Foo" as a key, and if the template has $ob.Foo, we both are happy.
This feature is one of the most powerful and beautiful, I think... :)
> one could replace the introspection call (in ASTIdentifier.execute()):
> executor = doIntrospection( c );
> by
> parser.introBuilder.doIntrospection( identifier, c );
Sure. Still wondering about the parser bit though.
> Profits:
> The possibility of having plugable introspection, even per Parser.
I see the benefit of pluggable introspection just for the modularity
alone, although I wouldn't be thrilled about including in the vel
distribution anything but a 'standard' introspection module, just for
sanity's sake, and to avoid encouraging people from doing things like
accessing things they shouldn't. 'public' and 'private' are there for a
reason :) Of course, that would be up for a general vote, I guess.
> Costs:
> - An extra member, and its initialization, for the Parser class. Since
> a pool of such objects is used, this is a very low cost.
> - A couple of extra references and an extra parameter to create the
> introspection. This is not such high cost either.
Yes, after thinking about it, there prollie wouldn't be much cost to it.
> Well, actually, maybe this costs less than keeping and initializing that
> "method" field (in the ASTIdentifier class) that is not being used any
> more.
> =;o)
Yes, that's just a leftover. Not sure how that relates here.
>
> What do you think about this?
>
> Paulo
>
> > -----Original Message-----
> > From: gmj@optonline.net [mailto:gmj@optonline.net]On Behalf Of Geir
> > Magnusson Jr.
> >
> > Before we consider that, does the above solve your problems?
> > Pluggable discovery sounds slow, and Vel isn't going anywhere big
> > unless we get to JSP-like performance.
> >
> > geir
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
RE: Case - plugable discovery proposal
Posted by Paulo Gaspar <pa...@krankikom.de>.
Geir,
Took sometime to get back at this (an interesting movie on TV).
Ok, there is a single point for introspection call which is from:
ASTIdentifier.doIntrospection( Class data )
Now, having:
public interface IntrospectionBuilder
{ public AbstractExecutor doIntrospection( String identifier, Class data )
throws Exception;
}
and an extra field for the Parser class like:
public final IntrospectionBuilder introBuilder;
one could replace the introspection call (in ASTIdentifier.execute()):
executor = doIntrospection( c );
by
parser.introBuilder.doIntrospection( identifier, c );
Profits:
The possibility of having plugable introspection, even per Parser.
Costs:
- An extra member, and its initialization, for the Parser class. Since
a pool of such objects is used, this is a very low cost.
- A couple of extra references and an extra parameter to create the
introspection. This is not such high cost either.
Well, actually, maybe this costs less than keeping and initializing that
"method" field (in the ASTIdentifier class) that is not being used any
more.
=;o)
What do you think about this?
Paulo
> -----Original Message-----
> From: gmj@optonline.net [mailto:gmj@optonline.net]On Behalf Of Geir
> Magnusson Jr.
>
> Before we consider that, does the above solve your problems?
> Pluggable discovery sounds slow, and Vel isn't going anywhere big
> unless we get to JSP-like performance.
>
> geir
RE: Case - plugable discovery proposal
Posted by Paulo Gaspar <pa...@krankikom.de>.
> -----Original Message-----
> From: gmj@optonline.net [mailto:gmj@optonline.net]On Behalf Of Geir
> Magnusson Jr.
>
> Paulo Gaspar wrote:
> >
> > Well, it is not a solution for all of my cases. Sometimes I have
> > objects with fields that are objects with fields... or arrays...
>
> True.
>
> > Using the methodizer would get require a lot of application side
> > coding and have quite some performance impact over the other
> > alternative.
>
> Not sure why there would be a performance impact?
I would have to use the methodizer on all of the objects with fields,
building a parallel data structure in some of the cases. And that
would still have to be "discovered". Only discovering with different
rules gives less trouble and is less redundant.
> ...
Have fun,
Paulo
Re: Case - plugable discovery proposal
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Paulo Gaspar wrote:
>
> Well, it is not a solution for all of my cases. Sometimes I have
> objects with fields that are objects with fields... or arrays...
True.
> Using the methodizer would get require a lot of application side
> coding and have quite some performance impact over the other
> alternative.
Not sure why there would be a performance impact?
> I will take a look around to better understand the performance impact
> of what I am talking about. The way I imagine thinks working, it
> shouldn't be any/much... but I might be wrong.
>
> Have fun,
> Paulo
>
> > -----Original Message-----
> > From: gmj@optonline.net [mailto:gmj@optonline.net]On Behalf Of Geir
> > Magnusson Jr.
> >
> > Paulo Gaspar wrote:
> > >
> > > For simple stuff I get lazy and use simple public fields instead of
> > > bean properties. And I like that. For many things it is not worth
> > > implementing all the gets and sets.
> >
> > Ugh. How about just using org.apache.velocity.util.FieldMethodizer?
> >
> > A little class used like :
> >
> > context.put("myclass", new FieldMethodizer( "MyClass" ) );
> >
> > and in template
> >
> > $myclass.publicstring
> >
> > (or whatever your public static fields are called...)
> >
> > >
> > > Not something I would want to impose as standard. WebMacro accepts it
> > > but I seems not to work with Velocity. For much of my stuff, I would
> > > also like discovery to be completely case insensitive.
> >
> > Discovery is now case insensitive, except for the FieldMethodizer, and
> > you might want to modify that and contribute it... If we are really 100%
> > supporting case insensitivity, the the FieldMethodizer should be the
> > same, eh?
> >
> > > But this would raise problems as those raised by Jon and so. So, I am
> > > not suggesting it to be part of Velocity's standard discovery.
> > >
> > > So, what about plugable discovery?
> > > =:o)
> >
> > Before we consider that, does the above solve your problems?
> > Pluggable discovery sounds slow, and Vel isn't going anywhere big
> > unless we get to JSP-like performance.
> >
> > geir
> >
> > >
> > > Paulo
> > >
> > > > -----Original Message-----
> > > > From: gmj@optonline.net [mailto:gmj@optonline.net]On Behalf Of Geir
> > > > Magnusson Jr.
> > > > Sent: Sunday, February 04, 2001 21:38
> > > >
> > > > Paulo Gaspar wrote:
> > > > >
> > > > > What about a plugable discovery mechanism?
> > > > >
> > > > > I want to volunteer to implement something like that since I
> > > > have a couple
> > > > > of discovery needs that I would not want to impose on other people.
> > > >
> > > > Like what?
> >
> > --
> > Geir Magnusson Jr. geirm@optonline.com
> > Velocity : it's not just a good idea. It should be the law.
> > http://jakarta.apache.org/velocity
> >
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
RE: Case - plugable discovery proposal
Posted by Paulo Gaspar <pa...@krankikom.de>.
Well, it is not a solution for all of my cases. Sometimes I have
objects with fields that are objects with fields... or arrays...
Using the methodizer would get require a lot of application side
coding and have quite some performance impact over the other
alternative.
I will take a look around to better understand the performance impact
of what I am talking about. The way I imagine thinks working, it
shouldn't be any/much... but I might be wrong.
Have fun,
Paulo
> -----Original Message-----
> From: gmj@optonline.net [mailto:gmj@optonline.net]On Behalf Of Geir
> Magnusson Jr.
>
> Paulo Gaspar wrote:
> >
> > For simple stuff I get lazy and use simple public fields instead of
> > bean properties. And I like that. For many things it is not worth
> > implementing all the gets and sets.
>
> Ugh. How about just using org.apache.velocity.util.FieldMethodizer?
>
> A little class used like :
>
> context.put("myclass", new FieldMethodizer( "MyClass" ) );
>
> and in template
>
> $myclass.publicstring
>
> (or whatever your public static fields are called...)
>
> >
> > Not something I would want to impose as standard. WebMacro accepts it
> > but I seems not to work with Velocity. For much of my stuff, I would
> > also like discovery to be completely case insensitive.
>
> Discovery is now case insensitive, except for the FieldMethodizer, and
> you might want to modify that and contribute it... If we are really 100%
> supporting case insensitivity, the the FieldMethodizer should be the
> same, eh?
>
> > But this would raise problems as those raised by Jon and so. So, I am
> > not suggesting it to be part of Velocity's standard discovery.
> >
> > So, what about plugable discovery?
> > =:o)
>
> Before we consider that, does the above solve your problems?
> Pluggable discovery sounds slow, and Vel isn't going anywhere big
> unless we get to JSP-like performance.
>
> geir
>
> >
> > Paulo
> >
> > > -----Original Message-----
> > > From: gmj@optonline.net [mailto:gmj@optonline.net]On Behalf Of Geir
> > > Magnusson Jr.
> > > Sent: Sunday, February 04, 2001 21:38
> > >
> > > Paulo Gaspar wrote:
> > > >
> > > > What about a plugable discovery mechanism?
> > > >
> > > > I want to volunteer to implement something like that since I
> > > have a couple
> > > > of discovery needs that I would not want to impose on other people.
> > >
> > > Like what?
>
> --
> Geir Magnusson Jr. geirm@optonline.com
> Velocity : it's not just a good idea. It should be the law.
> http://jakarta.apache.org/velocity
>
Re: Case - plugable discovery proposal
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Paulo Gaspar wrote:
>
> For simple stuff I get lazy and use simple public fields instead of
> bean properties. And I like that. For many things it is not worth
> implementing all the gets and sets.
Ugh. How about just using org.apache.velocity.util.FieldMethodizer?
A little class used like :
context.put("myclass", new FieldMethodizer( "MyClass" ) );
and in template
$myclass.publicstring
(or whatever your public static fields are called...)
>
> Not something I would want to impose as standard. WebMacro accepts it
> but I seems not to work with Velocity. For much of my stuff, I would
> also like discovery to be completely case insensitive.
Discovery is now case insensitive, except for the FieldMethodizer, and
you might want to modify that and contribute it... If we are really 100%
supporting case insensitivity, the the FieldMethodizer should be the
same, eh?
> But this would raise problems as those raised by Jon and so. So, I am
> not suggesting it to be part of Velocity's standard discovery.
>
> So, what about plugable discovery?
> =:o)
Before we consider that, does the above solve your problems?
Pluggable discovery sounds slow, and Vel isn't going anywhere big
unless we get to JSP-like performance.
geir
>
> Paulo
>
> > -----Original Message-----
> > From: gmj@optonline.net [mailto:gmj@optonline.net]On Behalf Of Geir
> > Magnusson Jr.
> > Sent: Sunday, February 04, 2001 21:38
> >
> > Paulo Gaspar wrote:
> > >
> > > What about a plugable discovery mechanism?
> > >
> > > I want to volunteer to implement something like that since I
> > have a couple
> > > of discovery needs that I would not want to impose on other people.
> >
> > Like what?
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
RE: Case - plugable discovery proposal
Posted by Paulo Gaspar <pa...@krankikom.de>.
For simple stuff I get lazy and use simple public fields instead of
bean properties. And I like that. For many things it is not worth
implementing all the gets and sets.
Not something I would want to impose as standard. WebMacro accepts it
but I seems not to work with Velocity. For much of my stuff, I would
also like discovery to be completely case insensitive.
But this would raise problems as those raised by Jon and so. So, I am
not suggesting it to be part of Velocity's standard discovery.
So, what about plugable discovery?
=:o)
Paulo
> -----Original Message-----
> From: gmj@optonline.net [mailto:gmj@optonline.net]On Behalf Of Geir
> Magnusson Jr.
> Sent: Sunday, February 04, 2001 21:38
>
> Paulo Gaspar wrote:
> >
> > What about a plugable discovery mechanism?
> >
> > I want to volunteer to implement something like that since I
> have a couple
> > of discovery needs that I would not want to impose on other people.
>
> Like what?
Re: Case - plugable discovery proposal
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
How did the Subject change?
Paulo Gaspar wrote:
>
> What about a plugable discovery mechanism?
>
> I want to volunteer to implement something like that since I have a couple
> of discovery needs that I would not want to impose on other people.
Like what?
>
> I have seen so many remarks on this and on WebMacro's list that it looks
> like a plugable mechanism makes a lot of sense, since what some people want
> often goes against the interest of others.
Like? I try to pay attention to WM, but what people seem to talk about
is bugs rather than alternate discovery approaches.
> The one thing that seems to make sense is to keep Velocity with a standard
> discovery mechanism as much compatible as possible to the beans standard,
> while allowing people to plug their own mechanism at Run Time.
>
> In my case, I would even want to use a of couple different mechanisms
> depending on the specific needs of each project.
>
> By the way, is the loader unification issue still open? I have some interest
> on implementing that one too, including some simple JDBC support.
>
> Have fun,
> Paulo Gaspar
>
> > -----Original Message-----
> > From: Jon Stevens [mailto:jon@latchkey.com]
> > Sent: Sunday, February 04, 2001 20:19
> >
> >
> > Ok,
> >
> > Here is a reason to *not* allow Geir's recent case "feature" into the
> > introspection...
> >
> > Page 40 of Sun's JMX Spec PDF ("jmx_instr_agent.pdf"):
> >
> > "Case Sensitivity
> >
> > All attribute and operation names derived from these design patterns are
> > case-sensitive. For example, this means that the methods getstate and
> > setState define two attributes, one called state that is
> > read-only, and one
> > called State that is write-only. While case sensitivity applies
> > directly to
> > component names of standard MBeans, it is also applicable to all component
> > names of all types of MBeans, standard or dynamic. In general,
> > all names of
> > classes, attributes, operations, methods, and internal elements defined in
> > the JMX specification are case sensitive, whether they appear as
> > data or as
> > functional code when they are manipulated by management operations."
> >
> >
> > Comments?
> >
> > -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/> | <http://java.apache.org/turbine/>
> >
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
RE: Case - plugable discovery proposal
Posted by Paulo Gaspar <pa...@krankikom.de>.
What about a plugable discovery mechanism?
I want to volunteer to implement something like that since I have a couple
of discovery needs that I would not want to impose on other people.
I have seen so many remarks on this and on WebMacro's list that it looks
like a plugable mechanism makes a lot of sense, since what some people want
often goes against the interest of others.
The one thing that seems to make sense is to keep Velocity with a standard
discovery mechanism as much compatible as possible to the beans standard,
while allowing people to plug their own mechanism at Run Time.
In my case, I would even want to use a of couple different mechanisms
depending on the specific needs of each project.
By the way, is the loader unification issue still open? I have some interest
on implementing that one too, including some simple JDBC support.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Jon Stevens [mailto:jon@latchkey.com]
> Sent: Sunday, February 04, 2001 20:19
>
>
> Ok,
>
> Here is a reason to *not* allow Geir's recent case "feature" into the
> introspection...
>
> Page 40 of Sun's JMX Spec PDF ("jmx_instr_agent.pdf"):
>
> "Case Sensitivity
>
> All attribute and operation names derived from these design patterns are
> case-sensitive. For example, this means that the methods getstate and
> setState define two attributes, one called state that is
> read-only, and one
> called State that is write-only. While case sensitivity applies
> directly to
> component names of standard MBeans, it is also applicable to all component
> names of all types of MBeans, standard or dynamic. In general,
> all names of
> classes, attributes, operations, methods, and internal elements defined in
> the JMX specification are case sensitive, whether they appear as
> data or as
> functional code when they are manipulated by management operations."
>
>
> Comments?
>
> -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/> | <http://java.apache.org/turbine/>
>