Re: Performance issue -> next release

2012-12-17 Thread mgreau
ok, no problem.



--
View this message in context: 
http://struts.1045723.n5.nabble.com/Performance-issue-next-release-tp5711393p5711432.html
Sent from the Struts - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org



Re: Performance issue -> next release

2012-12-17 Thread Lukasz Lenart
2012/12/17 mgreau :
> Hi,
>
> It's done : https://issues.apache.org/jira/browse/WW-3947

A bit to late ... but if we handle migration to new website publishing
mechanism I'm going prepare a new release asap :-)


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org



Re: Performance issue -> next release

2012-12-17 Thread mgreau
Hi,

It's done : https://issues.apache.org/jira/browse/WW-3947

Regards.
Maxime



--
View this message in context: 
http://struts.1045723.n5.nabble.com/Performance-issue-next-release-tp5711393p5711429.html
Sent from the Struts - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org



Re: Performance issue -> next release

2012-12-13 Thread Lukasz Lenart
2012/12/13 mgreau :
> Hi,
>
> I have to prepare a patch for the portlet archetype which doesn't work
> (${packageName} is not replace in Java classes and struts.xml).
>
> It's small changes which doesn't affect core code or plugins. Can it will be
> included in 2.3.8 release ?

Sure :-) Create an issue and attach the patch.


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org



Re: Performance issue -> next release

2012-12-13 Thread mgreau
Hi,

I have to prepare a patch for the portlet archetype which doesn't work
(${packageName} is not replace in Java classes and struts.xml).

It's small changes which doesn't affect core code or plugins. Can it will be
included in 2.3.8 release ?

Regards.
Maxime



--
View this message in context: 
http://struts.1045723.n5.nabble.com/Performance-issue-next-release-tp5711393p5711402.html
Sent from the Struts - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org



Re: Performance issue -> next release

2012-12-13 Thread Lukasz Lenart
2012/12/13 Johannes Geppert :
> +1 for an Xmas Release.
>
> @Łukasz
> Can we implement your suggested doStartTag Fix in 2.3.8?

No as this can be a breaking change and can introduce new issues -
just small improvements.


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org



Re: Performance issue -> next release

2012-12-13 Thread Johannes Geppert
+1 for an Xmas Release.

@Łukasz 
Can we implement your suggested doStartTag Fix in 2.3.8?

Johannes




-
web: http://www.jgeppert.com
twitter: http://twitter.com/jogep
--
View this message in context: 
http://struts.1045723.n5.nabble.com/Performance-issue-next-release-tp5711393p5711400.html
Sent from the Struts - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org



Re: Performance issue -> next release

2012-12-13 Thread Lukasz Lenart
The plan is as follow:

1. I'm going to solve few more issues till weekend (NPE, some small changes)
2. Release a test build during weekend
3. Give 3-4 days for testing
4. Call for a vote on wednesday
4. Finish release before Xmas


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org



Re: Performance issue -> next release

2012-12-13 Thread Philip Luppens
On Thu, Dec 13, 2012 at 7:43 AM, Lukasz Lenart wrote:

> 2012/12/12 Philip Luppens :
> > I'd say to go for it, but please do explain what the issue was for
> archival
> > reasons, since the original ticket[1] did not receive any update yet.
>
> Ok, you're right. The problem is related to my FileManager
> refactorings and introduced FileManagerFactory with default
> implementation
>
> ConfigurationManager#conditionalReload() from version 2.3.7 looks like
> this:
>
> public synchronized void conditionalReload(Container container) {
> FileManager fileManager =
> container.getInstance(FileManagerFactory.class).getFileManager();
> if (fileManager.isReloadingConfigs() || providersChanged) {
> 
> }
>
> so each time FileManager instance was looked up just to check if
> reloadConfigs flag is set to true, but right now it looks like this
> and the flag is checked directly
>
> public synchronized void conditionalReload(Container container) {
> boolean reloadConfigs =
> Boolean.parseBoolean(container.getInstance(String.class,
> XWorkConstants.RELOAD_XML_CONFIGURATION));
> if (reloadConfigs || providersChanged) {
> 
> }
>

Great, thank you very much for the writeup. I'm also in favor of a quick
release of 2.3.8 (I've just seen that AppFuse 2.2.1 was released with the
affected Struts 2.3.7).

Thanks again,

Phil


>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>


-- 
"We cannot change the cards we are dealt, just how we play the hand." -
Randy Pausch


Re: Performance issue -> next release

2012-12-12 Thread Lukasz Lenart
And there is still place for improvement, take a look at the
ComponentTagSupport#doStartTag, each time instance of Container is
taken from Dispatcher, which means each time configuration is checked
if needs to be reloaded - obviously it doesn't make sense to check
that or reload configuration during each tag execution. Configuration
should checked/reloaded on the beginning of request and stay constant
till the end of request.

So I think it is better to put Configuration into HttpServletRequest
(or wrapped one) and used it inside tags instead of using
Dispatcher.getInstance().getContainer().


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org



Re: Performance issue -> next release

2012-12-12 Thread Lukasz Lenart
2012/12/12 Philip Luppens :
> I'd say to go for it, but please do explain what the issue was for archival
> reasons, since the original ticket[1] did not receive any update yet.

Ok, you're right. The problem is related to my FileManager
refactorings and introduced FileManagerFactory with default
implementation

ConfigurationManager#conditionalReload() from version 2.3.7 looks like this:

public synchronized void conditionalReload(Container container) {
FileManager fileManager =
container.getInstance(FileManagerFactory.class).getFileManager();
if (fileManager.isReloadingConfigs() || providersChanged) {

}

so each time FileManager instance was looked up just to check if
reloadConfigs flag is set to true, but right now it looks like this
and the flag is checked directly

public synchronized void conditionalReload(Container container) {
boolean reloadConfigs =
Boolean.parseBoolean(container.getInstance(String.class,
XWorkConstants.RELOAD_XML_CONFIGURATION));
if (reloadConfigs || providersChanged) {

}


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org



Re: Performance issue -> next release

2012-12-12 Thread Philip Luppens
On Wed, Dec 12, 2012 at 6:30 PM, Łukasz Lenart wrote:

> Johannes discovered a huge performance issue which is already solved in
> trunk (2.3.8) so I'm going to prepare a new release ASAP. Is threre any
> other important outstanding issue that should be solved before the release?
>
> (on mobile)
>

I'd say to go for it, but please do explain what the issue was for archival
reasons, since the original ticket[1] did not receive any update yet.

- Phil

[1] https://issues.apache.org/jira/browse/WW-3941

-- 
"We cannot change the cards we are dealt, just how we play the hand." -
Randy Pausch


Performance issue -> next release

2012-12-12 Thread Łukasz Lenart
Johannes discovered a huge performance issue which is already solved in
trunk (2.3.8) so I'm going to prepare a new release ASAP. Is threre any
other important outstanding issue that should be solved before the release?

(on mobile)