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 an
On 9/29/06, Mario Ivankovits <[EMAIL PROTECTED]> 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 w
Hi!
> Yes, I did.
>
> Its a very simple one.
>
>
> No, I totally disagree.
>
> There is *zero* documentation on what the changes attempt to accomplish.
There is a one-liner above the code, maybe not the best english, but hey
its not zero ;-)
> Besides that, there seem to be a large number of
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
On 9/29/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi!
> Yes, I did.
>
> Its a very simple one.
>
>
> No, I totally disagree.
>
> There is *zero* documentation on what the changes attempt to accomplish.
There is a one-liner above the code, maybe not the best english, but hey
its not ze
Hi Craig!
Ok, lets concentrate only on the patch. Please, forget the discussion
about speedup, this has nothing to do with the patch.
I do not want to overload CONFIG_FILES nor change its meaning.
Say you have a web.xml with the following configuration:
javax.faces.CONFIG_FILES=/content/app/conf
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
+1
--
James Mitchell
678.910.8017
On Sep 28, 2006, at 9:41 PM, Craig McClanahan wrote:
The work we've done on the dialog support in the sandbox is showing
clear
earmarks of success. We can now support 100% of the functionality
that
actually works in the original implementation, plus ha
+1
On Sep 28, 2006, at 8:41 PM, Craig McClanahan wrote:
The work we've done on the dialog support in the sandbox is showing
clear
earmarks of success. We can now support 100% of the functionality
that
actually works in the original implementation, plus have addressed
a number
of outstandi
On 9/29/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi Craig!
Ok, lets concentrate only on the patch. Please, forget the discussion
about speedup, this has nothing to do with the patch.
I do not want to overload CONFIG_FILES nor change its meaning.
Say you have a web.xml with the following
Hi Craig,
or should I say - good morning :-)
>> javax.faces.CONFIG_FILES=/content/app/conf/faces-config.xml
>> ,/content/app2/conf/faces-config.xml
>
> OK, so lets continue the "twenty questions" game for a minute, and
> ask, why
> would you have a faces-config.xml file nested like this? JSF is
On 9/29/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi Craig,
or should I say - good morning :-)
Yep, at the moment :-).
javax.faces.CONFIG_FILES=/content/app/conf/faces-config.xml
>> ,/content/app2/conf/faces-config.xml
>
> OK, so lets continue the "twenty questions" game for a minute
Hi!
>> I had a look at the JSF-RI impl, there you will find in
>> ConfigureListener the method "getContextURLForPath" which will be used
>> to lookup the configuration files configured in
>> javax.faces.CONFIG_FILES. This method use
>> ServletContext.getResource(path) - the same as shale-tiger use,
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
On 9/29/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi!
>> I had a look at the JSF-RI impl, there you will find in
>> ConfigureListener the method "getContextURLForPath" which will be used
>> to lookup the configuration files configured in
>> javax.faces.CONFIG_FILES. This method use
>> Serv
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 ever
The code review tool flags the instance variable data (the dialog
data) being declared as an Object, in relevant places in both the
basic and scxml impl. While we do document the fact that dialog data
should be Serializable, we do not enforce that in code. Any downside
to changing the type of 'dat
On 9/29/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
The code review tool flags the instance variable data (the dialog
data) being declared as an Object, in relevant places in both the
basic and scxml impl. While we do document the fact that dialog data
should be Serializable, we do not enforce
On 9/29/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 9/29/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
>
> The code review tool flags the instance variable data (the dialog
> data) being declared as an Object, in relevant places in both the
> basic and scxml impl. While we do document the f
19 matches
Mail list logo
