On 9/28/06, Mario Ivankovits (JIRA) <[EMAIL PROTECTED]> wrote:
[
http://issues.apache.org/struts/browse/SHALE-295?page=comments#action_38300]
Mario Ivankovits commented on SHALE-295:
----------------------------------------
No, you misunderstood me. BTW: I am a hibernate etc. user, I know what it
means to have tons of dependencies. (We have 91 of them - excluding our own
app)
Crag, did you look at the patch?
Yes, I did.
Its a very simple one.
No, I totally disagree.
There is *zero* documentation on what the changes attempt to accomplish.
Besides that, there seem to be a large number of changes that are (from the
viewpoint of an external person) totally gratuitous -- such as changing data
types from List<...> to Collection<...>. The amount of such changes makes
the ultimate intent of what you are trying to do totally invisible to me.
If you can't even describe to the initial author of this code what you're
trying to do, and how, it's not going to go very far :-).
You will see, that it uses explicitResources() (your method in
LifeCycleListener2) to get a list of URLs of all explicitely configures
faces-config.xml.
Then, it simply gets the jarfile from the urlConnection.
No additional scanning takes places.
Its just, that shale-tiger not only recognizes META-INF/faces-config.xmlas
faces-app, but also those jars which contain a
faces-config.xml, assumed, that the pointer to the faces-config.xml is
configured through CONFIG_FILES configuration.
This is code already running in LifeCycleListener2, now, its just reused
for a different thing, there is no performance penalty.
As far as I understood your patch, you were planning to remove the condition
about jars that had a META-INF/faces-conifg.xml file. Is that not the
acase?
If you were intending to remove this restriction, and replace it with a test
for whether the JAR includes a class with a package configured in a config
parameter, then I'm likely to remain -1 on this approach, for the reasons
stated in earlier responses on the threads related to this change. Please
explain to me how, if I happen to have an app with hibernate (and its
dependencies) *and* declare a set of packges with your proposed config
parameter, you will eliminate the need to analize the Hibernate JAR itself,
or any of its non-JSF-related dependencies.
AFAICT, your proposed approach makes the environment worse, rather than
better.
Craig
collect web archives with explicit configured faces-config.xml pointing to
them
>
-------------------------------------------------------------------------------
>
> Key: SHALE-295
> URL: http://issues.apache.org/struts/browse/SHALE-295
> Project: Shale
> Issue Type: Improvement
> Components: Tiger
> Reporter: Mario Ivankovits
> Attachments: explicit_jars.diff
>
>
> The patch will also collect jars in WEB-INF/lib which have a
faces-config.xml pointing to them through the configuration
javax.faces.CONFIG_FILES
> That way, you no longer need to have a "marker" faces-config.xml in
META-INF.
> The patch is not heavily tested yet.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
