[tiger] speedup of startup and extension to view annotation

[Mario Ivankovits <ma...@ops.co.at>]

Hi!

I would like to discuss two things which come in my mind during trying
out shale-tiger:

1) Speedup of startup
While shale-tiger already tries its best to parse only jars with
specific markers I think we can further speedup the startup if we allow
the user to configure which packages to parse.
I think about a context parameter where the user can configure e.g.
"org.my.app1.backings,org.my.app2.backings" etc.
This will parse classes located within these packages and their
sub-packages.
There are tricks how to get the classes within an package, I already use
such a trick, though, with help from VFS, but it should be backportable
to plain java.

I know, this is yet another context-param, but the speedup might be
worth it.

BTW: Having such a configureable framework in commons might be great -
or as part of the "web commons" (sorry I've forgotten the name ;-) )
would be great. Any library can register to it and do not need to create
all this traversing code itself, but well, we can easily refactor it
later ....


2) extension to @View annotation

The ViewControllerMapper is responsible to map a view name to the
corresponding backing name. Now, with the power of annotations it might
be possible to use another approach to map a bean to its view.

Say a bean has both annotations, the @View and @Bean, now, if we allow
to setup the view name at the @View tag, e.g.
@View(name="/to/my/faces/view.jsp")
Shale has all informations required to map a view to the bean.
"name" should be optional so one can still use the ViewControllerMapper.

What do you think?
I'll provide patches if you think its useful.

Ciao,
Mario

[tiger] speedup of startup [was: [tiger] speedup of startup and extension to view annotation]

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
> For the speedup thing (with a new context parameter) I'll try to
> implement my thoughts in LifecycleListener2 and create a simple benchmark.
> Then we will see if its worth it.
>   
I created https://issues.apache.org/struts/browse/SHALE-301 with a first
try to speedup startup times, so everyone can download it and give it a try.

As written in the issue, if we would like to add it to the codebase,
I'll do the test-case, documentation thing.


Ciao,
Mario

Re: [tiger] speedup of startup and extension to view annotation

[Mario Ivankovits <ma...@ops.co.at>]

Hi Craig!

I wont leave this mailing list ;-)

For the speedup thing (with a new context parameter) I'll try to
implement my thoughts in LifecycleListener2 and create a simple benchmark.
Then we will see if its worth it.

Ciao,
Mario

Re: [tiger] speedup of startup and extension to view annotation

[Mario Ivankovits <ma...@ops.co.at>]

Hi Craig!

Please be patience with me, maybe I'll get better after having a coffee ...

>>
>> You do NOT have to scan all classes. Thats the point.
>
> Your patch, including the embedded comments, is completely opaque on this
> question.
This is due to the fact that the patch was not meant to be a solution
for the mailing list discussion.

>   You haven't answered my repeated requests to explain *what* this
> patch is supposed to do
Take jars into account which have a faces-config.xml in another place
than META-INF/faces-config.xml.
Not by scanning all jars, but by using getResource() (as in
expliciteResource() ) with the path taken from CONFIG_FILES

I thought this patch is easy and without any side effect.


THEN, I wanted to start a discussion about how to find a different style
to get the list of classes to scan.
Maybe with the conclusion that we don't want to have it.

Ciao,
Mario

Re: [tiger] speedup of startup and extension to view annotation

[Craig McClanahan <cr...@apache.org>]

On 9/29/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi Craig!
> >> >> 1) Speedup of startup
> >
> > See my response on your JIRA issue ...
> The JIRA issue and this topic are two completely different things.
> Please take a look at the patch and you'll see.


If that is the case, then please comply with my initial request on the JIRA
issue.  I have absolutely no clue what this change is intended to
accomplish.

> if the developer *does* include this
> > context init parameter, then it seem that we would have to analyze *all*
> > JARs in WEB-INF/lib,
> No. You can get access to a package listing by.
> * converting the class name to a path name: org.apache.shale =
> org/apache/shale
> * then use classLoader.getResources(path)
> then you'll get a list of urls where you can get a "directory listing"
> of (even if within an jar)
> * then convert the "directory listing" back to class names
> * scan the classes
>
> you are done ...
>
> You do NOT have to scan all classes. Thats the point.


Your patch, including the embedded comments, is completely opaque on this
question.  You haven't answered my repeated requests to explain *what* this
patch is supposed to do, let alone *why* it would be better.  Without
answers to both of those questions, it is guaranteed that *I* will not be
applying this patch to the codebase.

Ciao,
> Mario
>
>
Craig

Re: [tiger] speedup of startup and extension to view annotation

[Mario Ivankovits <ma...@ops.co.at>]

Hi Craig!
>> >> 1) Speedup of startup
>
> See my response on your JIRA issue ...
The JIRA issue and this topic are two completely different things.
Please take a look at the patch and you'll see.

> if the developer *does* include this
> context init parameter, then it seem that we would have to analyze *all*
> JARs in WEB-INF/lib,
No. You can get access to a package listing by.
* converting the class name to a path name: org.apache.shale =
org/apache/shale
* then use classLoader.getResources(path)
then you'll get a list of urls where you can get a "directory listing"
of (even if within an jar)
* then convert the "directory listing" back to class names
* scan the classes

you are done ...

You do NOT have to scan all classes. Thats the point.


Ciao,
Mario

Re: [tiger] speedup of startup and extension to view annotation

[Craig McClanahan <cr...@apache.org>]

On 9/28/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi Craig!
>
> >> 1) Speedup of startup
> > ... because it expects the developer to have a fairly complete
> > understanding of all the classes in every jar, even if you got it from a
> > third party.
> oh yes, right you are ....
>
> So the syntax of the configuration should be somehow different:
>
> classes=org.any.faces.beans,super-3rdparty.jar=*,
> myapp.jar=com.company.faces.backings,com.company.faces2.backings,
> mapp2.jar=....
> etc
>
> That way you do not need to know much about super-3rdparty.jar, just
> that it might contain beans.
>
> And notice, you do not need to configure it, if there is no
> configuration you do not need to take this burden, just the current
> behavior apply.


See my response on your JIRA issue ... if the developer *does* include this
context init parameter, then it seem that we would have to analyze *all*
JARs in WEB-INF/lib, even those that are pretty much guaranteed *not* to
have anytihing relevant (such as Hibernate and all of its dependencies).
>From my viewpoint, implementing this approach seems like a net loss in
performance (for the normal use cases), rather than a gain.

> If the
> > class is ultimately used later, one could argue that cost is worth the
> > price,
> But you might have only a handful beans compared to the number of
> classes you find in the jars. If you know the package you can decrease
> the number of scanned classes.


Doesn't matter ... the key to improving performance is minimizing the list
of classes you ever look at in the first place (and therefore have to load
into memory in the JVM).  If you explicitly specify that any class in "
com.mycompany.mypackage.mybeans" might include annotated beans, then you are
implicitly requiring Shale to check for such classes in *all* jars included
in the webapp ... even if they came from something like Hibernate.

> It might well be a nice addition to a commons project, but I'm getting
> > allergic to increasing the number of dependencies.  Indeed, I'd rather
> > focus
> > on decreasing  them :-).
> Yea, same old story ... all the time ... we create reusable code, but
> don't want to depend on it :-(
>
> > 2) extension to @View annotation
> >
> > This seems like a good idea.
> ...
> > Maybe something like the way that LifecycleListener
> > transparently
> > delegates toi LifecycleListener2 could be added to the default mapper
> > implementation.
> Ok, I'll have a look at it that way.
>
>
> Ciao,
> Mario
>
>

Craig

Re: [tiger] speedup of startup and extension to view annotation

[Mario Ivankovits <ma...@ops.co.at>]

Hi Craig!

>> 1) Speedup of startup
> ... because it expects the developer to have a fairly complete
> understanding of all the classes in every jar, even if you got it from a
> third party.
oh yes, right you are ....

So the syntax of the configuration should be somehow different:

classes=org.any.faces.beans,super-3rdparty.jar=*,myapp.jar=com.company.faces.backings,com.company.faces2.backings,mapp2.jar=....
etc

That way you do not need to know much about super-3rdparty.jar, just
that it might contain beans.

And notice, you do not need to configure it, if there is no
configuration you do not need to take this burden, just the current
behavior apply.

> If the
> class is ultimately used later, one could argue that cost is worth the
> price,
But you might have only a handful beans compared to the number of
classes you find in the jars. If you know the package you can decrease
the number of scanned classes.

> It might well be a nice addition to a commons project, but I'm getting
> allergic to increasing the number of dependencies.  Indeed, I'd rather
> focus
> on decreasing  them :-).
Yea, same old story ... all the time ... we create reusable code, but
don't want to depend on it :-(

> 2) extension to @View annotation
>
> This seems like a good idea.  
...
> Maybe something like the way that LifecycleListener
> transparently
> delegates toi LifecycleListener2 could be added to the default mapper
> implementation.
Ok, I'll have a look at it that way.


Ciao,
Mario

Re: [tiger] speedup of startup and extension to view annotation

[Craig McClanahan <cr...@apache.org>]

On 9/28/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi!
>
> I would like to discuss two things which come in my mind during trying
> out shale-tiger:
>
> 1) Speedup of startup
> While shale-tiger already tries its best to parse only jars with
> specific markers I think we can further speedup the startup if we allow
> the user to configure which packages to parse.
> I think about a context parameter where the user can configure e.g.
> "org.my.app1.backings,org.my.app2.backings" etc.
> This will parse classes located within these packages and their
> sub-packages.
> There are tricks how to get the classes within an package, I already use
> such a trick, though, with help from VFS, but it should be backportable
> to plain java.
>
> I know, this is yet another context-param, but the speedup might be
> worth it.


Are you thinking that, if the list of packages was specified, that it would
apply to *all* of the JAR files (and, presumably, when you scan
/WEB-INF/classes for consistency)?  If so, that seems like a pretty heavy
usability burden, because it expects the developer to have a fairly complete
understanding of all the classes in every jar, even if you got it from a
third party.

Also, note that the impact we are talking about here is the fact that Shale
has to load the class in order to analyze its runtime annotations.  If the
class is ultimately used later, one could argue that cost is worth the
price, because it saves having to load the class later.  The only time that
Shale's loading of the class is "wasted effort" is if the class will never
be used.

BTW: Having such a configureable framework in commons might be great -
> or as part of the "web commons" (sorry I've forgotten the name ;-) )
> would be great. Any library can register to it and do not need to create
> all this traversing code itself, but well, we can easily refactor it
> later ....


It might well be a nice addition to a commons project, but I'm getting
allergic to increasing the number of dependencies.  Indeed, I'd rather focus
on decreasing  them :-).

2) extension to @View annotation
>
> The ViewControllerMapper is responsible to map a view name to the
> corresponding backing name. Now, with the power of annotations it might
> be possible to use another approach to map a bean to its view.
>
> Say a bean has both annotations, the @View and @Bean, now, if we allow
> to setup the view name at the @View tag, e.g.
> @View(name="/to/my/faces/view.jsp")
> Shale has all informations required to map a view to the bean.
> "name" should be optional so one can still use the ViewControllerMapper.


This seems like a good idea.  I presume we would want this to explicitly
override any default mapping for this particular view id, but (if it were
not specified) the standard implementation would be used.  In terms of
implementation, we'll also need to take care with configuration, since we
can't guarantee that shale-tiger.jar will be configured after
shale-core.jaris.  Maybe something like the way that LifecycleListener
transparently
delegates toi LifecycleListener2 could be added to the default mapper
implementation.

What do you think?
> I'll provide patches if you think its useful.
>
> Ciao,
> Mario
>
> Craig