Re: [S2] Release Plan for 2.0.8

[David H. DeWolf]

The tiles 2.0.4 vote was recapped today (and passed as the first tiles2 
beta). Antonio is working on finalizing/pushing the release.


The struts2-tiles plugin depends upon 2.0.3, which is already released, 
so I'm not sure what the holdup is.


David


Rainer Hermanns wrote:

Hey there,

if there are no objections, I'd like to roll the 2.0.8 release tomorrow.

What is the status of WW-1943 [1]?
IIRC only a tiles release was missing for the release.

Please correct me if I'm wrong.

cheers,
Rainer

[1] http://issues.apache.org/struts/browse/WW-1943




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] [VOTE] Struts 2.0.7 Quality

[David H. DeWolf]

Agreed, but that doesn't prevent us from finalizing 2.0.7 as beta though 
does it?  Since most of the work is already done, it seems worth putting 
out there for those that prefer the other 2.0.7 fixes to the i18n tag?


Ted Husted wrote:

I doubt that there will be enough binding GA votes for the release
when the i18n tag is broken. We'll just have to go on to 2.0.8 as soon
as a new XW release is available.

-Ted.

On 3/27/07, Rene Gielen <[EMAIL PROTECTED]> wrote:

I should have fixed the according XWork issue [1] for XW 2.0.2-SNAPSHOT.
   To fix WW-1856, we have to upgrade XWork dependency.

Unfortunately, the conditions under which this issue shows up are far
from rare. Any use of the i18n tag is likely to cause troubles. I can
reproduce various cases where a simple POST with an Action.execute()
target produces unreadable pages due to inproper text resolving.

Therefore I would consider this issue as blocker for making 2.0.7 a GA
release. Thoughts?

Regards,
- Rene

[1] http://jira.opensymphony.com/browse/XW-487

Rene Gielen schrieb:
> I seem to have the same issue here in a customer project, but since 
it is portlet environment, I was not sure yet whether it was a porlet 
related issue...

>
> - Rene
>
> On Tue, 27 Mar 2007 10:55:27 +0200 (CEST), "Rainer Hermanns" 
<[EMAIL PROTECTED]> wrote:

>> James,
>>
>> there is a blocking error for xwork 2.0.2 [1] that seems to be 
related.

>> I am trying to work on this the coming weekend and release xw 2.0.2
>> ASAP with this and other fixes.
>>
>> +1 for beta
>>
>> cheers,
>> Rainer
>>
>> [1] http://jira.opensymphony.com/browse/XW-487
>>
>>> In trying to fix a few insignificant items in the the mailreader, and
>>> I'm seeing some weirdness in the i18n tagby weirdness, I mean
>>> that it's broke.
>>>
>>> Can someone confirm?
>>>
>>> If so, my vote goes to +1 for beta.
>>>
>>>
>>> --
>>> James Mitchell
>>> The Ruby Roundup
>>> http://www.rubyroundup.com/
>>>
>>>
>>> On Mar 21, 2007, at 4:59 PM, Ted Husted wrote:
>>>
 The Struts 2.0.7 test build is now available.

Release notes:

* http://struts.apache.org/2.x/docs/release-notes-207.html

Distribution:

* http://people.apache.org/builds/struts/2.0.7/

The Maven 2 staging repository is not yet available, but when it
 is, it will be in the usual location:

* http://people.apache.org/builds/struts/2.0.7/m2-staging-
 repository/

Once you have had a chance to review the test build, please
 respond with a vote on its quality:

[ ] Leave at test build
[ ] Alpha
[ ] Beta
[ ] General Availability (GA)

Everyone who has tested the build is invited to vote. Votes by 
PMC

 members are considered binding. A vote passes if there are at least
 three binding +1s and more +1s than -1s.

The vote will remain open for at least 72 hours, longer upon
 request. A vote can be amended at any time to upgrade or 
downgrade the
 quality of the release based on future experience. If an initial 
vote

 designates the build as "Beta", the release will be submitted for
 mirroring and announced to the user list. Once released as a public
 beta, subsequent quality votes on a build may be held on the user
 list.

As always, the act of voting carries certain obligations. A
 binding vote not only states an opinion, but means that the voter is
 agreeing to help do the work

 -Ted.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s1] Tiles 2 support situation

[David H. DeWolf]

Both of these are temporary solutions. . .

Why not push another tiles release?  Aren't we at (or at least nearing) 
another milestone anyways?


David

Antonio Petrelli wrote:

Hi all
As you may have noticed, I added recently Tiles 2 support to Struts 1.
Currently it relies on an unpublished snapshot of Tiles 2.
I thought that, simply because I was working in the trunk, it wasn't a
big issue, until we decide to begin to roll out a 1.4.0 version of
Struts.
But a JIRA issue:
http://issues.apache.org/struts/browse/STR-3017
unburied a big problem: no one can build Struts 1 in the trunk.
So what is the best thing to do?
1) move Struts 1- Tiles 2 to the sandbox
2) remove the tiles2 module from its parent pom, so at least Struts 1 
compile.


Let me know your thoughts.
Antonio

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] [VOTE] Struts 2.0.7 Quality

[David H. DeWolf]

Ted Husted wrote:

+1


   [ ] Leave at test build
   [ ] Alpha
   [ ] Beta
   [x] General Availability (GA)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] Struts 2.0.7 Status

[David H. DeWolf]

Where is this failing for you?  Step 4?

 mvn clean install site -P all,alljars,pre-assembly

works fine for me when using the 2.0.7 tag.


James Mitchell wrote:
There's no api/ under STRUTS_2_0_X branch, so the assembly is failing.  
I made a quick fix to remove those references () and trying again.


I suppose I should commit this, unless we need the api as part of the 
distribution.  If so, which Jira should I reference?



--
James Mitchell
The Ruby Roundup
http://www.rubyroundup.com/


On Mar 21, 2007, at 12:57 PM, James Mitchell wrote:


Ok, I'll do it.

So, going from the below wiki page, there's a couple of steps that 
I'll have to do prior to #6.  I know I need to at least start at #4.  
So I'll start there.




--
James Mitchell
The Ruby Roundup
http://www.rubyroundup.com/


On Mar 21, 2007, at 12:43 PM, Ted Husted wrote:


Nope.

On 3/21/07, James Mitchell <[EMAIL PROTECTED]> wrote:

Have you found a volunteer yet?


--
James Mitchell
The Ruby Roundup
http://www.rubyroundup.com/


On Mar 21, 2007, at 8:22 AM, Ted Husted wrote:

> We need another volunteer to perform step #6 of the release gauntlet,
> which stages the JARs as Maven artifacts
>
> * http://struts.apache.org/2.x/docs/creating-and-signing-a-
> distribution.html
>
> My CygWin SSH setup is still muddled. I tried running it using
> password authentication three times, but did fails to complete the
> process each time.
>
> Everything else is done, and it's just a matter of whether we want to
> post the artifacts to the Maven repository as part of our release.
>
> If no one steps up, I'll call the vote anyway, and we can let the
> PMC decide.
>
> -Ted.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--HTH, Ted 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] Enhancement to Zero Config: Default Success Result

[David H. DeWolf]

mraible wrote:

Yes, this is what I'm looking for, and I was able to use it successfully.
Strangely enough, I couldn't get the @Result annotation to work with zero
config.  Is there anything special I need to do for that?


I use it and don't recall anything special.  Do you have errors that are 
occurring? What happens when you try to use it?




One change I'd like to see to the codebehind plugin is the ability to
specify the default location of pages. For example WEB-INF/pages.  Or is
that what the "struts.codebehind.defaultPackage" constant is for? 


I'd also like to expand support so that all result values can be used as 
post fixes.  Instead of supporting just page-success.jsp and 
page-input.jsp, why not support page-whatevertheresultis.jsp.  Thoughts?




I think it makes sense to combine Zero Config and Code Behind as they both
seem to be doing the same thing.  Zero config means no config, and if
there's still an @Result required - that's configuration, no? ;-)


I have a hard time envisioning someone using them separately as well. . .

-D


Thanks,

Matt


Tom Schneider-4 wrote:

See http://struts.apache.org/2.x/docs/codebehind-plugin.html

The very first line from the docs are:
*
Default results* - The purpose of most Actions is to execute code to 
prepare the data for a specific page. The name of this page is often the 
same as the Action itself.


Is this not what your looking for, or is there more to it?  I've seen 
the Spring MVC support for this and this looks like exactly the same 
functionality to me.  In fact the struts version is more flexible 
because it looks for /NAMESPACE/ACTION-RESULT.jsp as well as 
/NAMESPACE/ACTION.jsp.

Tom

mraible wrote:

Is there a default success result when using Zero configuration?  I'd
like to
see this feature added.  Spring MVC has something similar, as does
Tapestry.
It's quite nice to simple create a controller, as well as a view without
having to configure anything.

http://www.springframework.org/docs/reference/mvc.html#mvc-coc-r2vnt

Implementation ideas: specify the default directory on the filter, then
name
the JSP the same as the URL.

For example, TestAction would expect a test.jsp page.

Specify the default result type should be possible in struts.xml.  Maybe
this setting should go there as well.  


Does the actionPackages configuration belong in struts.xml instead of
web.xml?

Thanks,

Matt
  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Struts 2.0.6 Quality

[David H. DeWolf]

The struts2-continuations-plugin/ is missing from the maven 
repositories, builds, and tag for 2.0.6.   It was there for 2.0.5. Is 
that intentional?  If not, it should be fixed prior to 2.0.7.



David
.
Ted Husted wrote:

Here's my own +1 for GA.

That makes the tally

Binding

3 +1 GA - Patrick Lightbody, Rainer Hermanns, Ted Husted.

1 +1 Beta - Rene Gielen.

Non-Binding

5 +1 GA - Dave Newton, Matt Raible, Nate Drake, Andre Faria, Philip 
Luppens.


1 +1 Beta - Pedro Herrera.

1 +1 Test Build - cilquirm.

I'll submit the distribution for mirroring and tomorrow make the GA
announcement to [EMAIL PROTECTED]

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Performance ... again

[David H. DeWolf]

Mike Baroukh wrote:

 I made some tests and yes, it's very slow : on my PIV, 3Ghz, each 
call to getText() take approximatively 200ms.


These are similar to the initial numbers that I saw, however, after 
tweaking my configuration, my getText() invocations are much faster than 
that - consistently between 5-15 ms.  Are you absolutely sure that all 
i18n reloading is off?  There are a couple of ways to enable it, not 
just one.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Struts 2.0.5 Quality

[David H. DeWolf]

Ted Husted wrote:


[  ] Leave at test build
[  ] Alpha
[  ] Beta
[ X ] General Availability (GA)


+1 GA

Deployed and tested into our qa environment without any glitches. 
Moving to production soon without any reservations.






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts Release Process (again) (was [VOTE] Struts 2.0.5 Quality)

[David H. DeWolf]

Rene Gielen wrote:

Craig,

So feature freeze and branch 2.0.x now, only fix reported bugs from beta
tests and roll out the result as GA, while trunk moves on to 2.1.x,
fully open for new features and whatever? IMO this would be the perfect
way to go, you get a big +1 from me on this :)


+1 As well.



- Rene

Craig McClanahan schrieb:

On 2/6/07, Don Brown <[EMAIL PROTECTED]> wrote:

Alexandru Popescu wrote:

I see two clear stages:

- a product that is ready from developers point of view
- a product that gets its users acceptance

[...]


That is definitely one of the lessons to be learned from the Struts
1.xexperience.  Here's how we're applying that lesson in Shale land.
The
recent 1.0.4 release is the first one we felt had a snowball's chance at
being voted GA quality, so as soon as we cut that release we also branched
(SHALE_1_0_X), with the rule that only bugfixes (including non-invasive
bugfixes backported from the trunk) would be committed here.  The trunk was
then opened for further "new feature" development (as well as bugfixes).
Right now, it is tentatively labelled as "1.1.0-SNAPSHOT", but that could
easily become 2.0.0-SNAPSHOT if we wanted to do major
non-backwards-compatible changes.

The net effect is that Struts could:

* Create a branch totally focused on stabilization and bugfixes ... the
only
*point*
 is to create a GA-quality branch based on the current feature set.  If
2.0.5 does not
 cut the mustard, just fix the reported bugs and try again (weeks instead
of years later).

* Avoid slowing down new feature development ... it continues on the trunk.

* If 2.05 (say) got voted GA but a security vulnerability or critical bug
were later
 discovered, an updated version could be turned around VERY quickly on the
 branch.  Just fix the bad problems and release it.  You don't have to
worry about
 stabilizing all the new features that might have been added on the trunk,
because
 they won't be present on the branch.  (The MyFaces folks are currently
paying
 the same price we paid in 1.x, because they are intermixing new features
and
 bugfixes on the trunk -- hopefully they will learn the same lesson.)

Branches are our friends.  The fact that we didn't leverage them is the
biggest thing we did wrong in Struts 1.x development, IMHO.  I hope that
the
Struts 2 process can improve based on lessons learned from that experience.

Don


Craig



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Future of Struts API (was ServletRequestAware Interface doubled)

[David H. DeWolf]

Ted Husted wrote:

I tend to agree. Unless someone says they are ready, willing, and
ablle to resolve the "new API" this weekend, lets just pull it out and
roll 2.0.5 now.


+1


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

License Headers (was Re: ServletRequestAware Interface doubled)

[David H. DeWolf]

One thing I did notice when looking through the api quickly is that
a lot of the api doesn't have license headers.  We should probably fix 
that ASAP.


https://issues.apache.org/struts/browse/WW-1698

Does this mean we should stop the current release that's about to go out?

David

Rene Gielen wrote:

Working on the ProxyPrincipal problem, I discovered that we have two
different ServletRequestAware interfaces:
- org.apache.struts2.servlet.ServletRequestAware in api
- org.apache.struts2.interceptor.ServletRequestAware in core

I doubt this is by intention. ServletConfigInterceptor uses the second
variant, which is IMO bad choice and makes it difficult to remove it in
favor for the api variant, as it will most likely break many users code.
On the other hand, since we are not in production yet, we should work on
clean interfaces and risk some minor/easy to fix code breaks for users.

I'm +1 for dropping the core variant.

- Rene

--
Rene Gielen  | http://it-neering.net/
Aachen   | PGP-ID: BECB785A
Germany  | gielen at it-neering.net


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ServletRequestAware Interface doubled

[David H. DeWolf]

Then should we remove the dependency on the api from core to prevent 
confusion?


Rainer Hermanns wrote:

-1, IIRC the API is not yet in place, but shall be the foundation for the
upcoming xwork abstraction.
Who can give us an update on the current API status?
Since the API is not yet implemented at all, I think there is currently no
need to remove anything, before the API has been finalized.

-Rainer


On 2/1/07, Rene Gielen <[EMAIL PROTECTED]> wrote:

I doubt this is by intention. ServletConfigInterceptor uses the second
variant, which is IMO bad choice and makes it difficult to remove it in
favor for the api variant, as it will most likely break many users code.
On the other hand, since we are not in production yet, we should work on
clean interfaces and risk some minor/easy to fix code breaks for users.


+1 -- now is the time, definitely.


--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com

"The truth is that we learned from João forever to be out of tune."
-- Caetano Veloso






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Experimental Features

[David H. DeWolf]

I'm also using codebehind and zero config.  Is it time to promote them 
from experimental?


Patrick Lightbody wrote:

I use all of these with HostedQA.


It's exciting to see that we've added a number of
brave, new features
since Struts 2.0.1.

* codebehind plugin
* zero configuration
* REST-ful URLS
* direct results

As implemented, these features seem solid and useful,
but I wonder if
anyone has a chance to use them all beyond "proof of
concept"
examples. (Wendy?)

If not, I would suggest that we consider documenting
these features as
"experimental" for Struts 2.0.2, until we have had a
chance to put
them to use ourselves in our own applications.

Of course, one GA in a series is only the beginning,
and we can soon
bring out another 2.0.x that promotes the
"experimental" features to
"mainstream".

-Ted.

--
---
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]



-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=52728&messageID=120092#120092


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: per-method validations for annotations

[David H. DeWolf]

Yes, but that requires seperate validations config per method - even if 
they are identical.


Take a dumb example. . .suppose you have an action with simple methods:

load
create
update
delete

Perhaps you have the same validation on create and update, but do not 
want them to execute on load and delete.


If I want per-method validation, I would have to create two distinct 
validation.xml files (CrudAction-create-validation.xml & 
CrudAction-update-validation.xml) as opposed to only one which is 
"activated" for the specific action methods I want validation to occur on.


Are there any ways around the duplication problem that I'm not aware of?

David

Ted Husted wrote:

Per-method validations are supported, using the convention

* ActionClass-actionMethod-validation.xml

This approach doesn't work with "dynamic method invocation" though
(the WW ! notation), because of the way DMI is implemented. Per method
validation does work with wildcards, though.

-Ted.

On 1/29/07, David Rupp <[EMAIL PROTECTED]> wrote:

Hi, all.

I've submitted a patch to the XWork project (issue XW-470) that
enables per-method validations when using annotations. This is, IMO,
an improvement over the current behavior, with which all validations
are attached to the class, and *all* fire when *any* method is
executed. Since validation annotations, by definition, *must* be
defined on a specific method, it seems more reasonable to expect that
the validations defined on a given method would fire when - and only
when - that method is executed.

I have a specific need for this behavior on my current project, but
I'd rather not be in the position of maintaining a forked version of
XWork just for it. I'd love it if some of the folks from this group
could take a look at my patch (included on the issue) and let me know
how it can be improved, assuming I'm not the only one who would like
to see this behavior implemented.

Regards,
David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: per-method validations for annotations

[David H. DeWolf]

It's something I actually will be needing in the near future.  If no one 
beats me, I'll probably take a look at the patch (late?) next week.


David

Laurie Harper wrote:

David Rupp wrote:

Hi, all.

I've submitted a patch to the XWork project (issue XW-470) that 
enables per-method validations when using annotations. This is, IMO, 
an improvement over the current behavior, with which all validations 
are attached to the class, and *all* fire when *any* method is 
executed. Since validation annotations, by definition, *must* be 
defined on a specific method, it seems more reasonable to expect that 
the validations defined on a given method would fire when - and only 
when - that method is executed.


I have a specific need for this behavior on my current project, but 
I'd rather not be in the position of maintaining a forked version of 
XWork just for it. I'd love it if some of the folks from this group 
could take a look at my patch (included on the issue) and let me know 
how it can be improved, assuming I'm not the only one who would like 
to see this behavior implemented.


+1, since we've already had at least one user expecting it to work like 
this and it would certainly make the framework more flexible. I haven't 
looked at the patch but I'd like to see this functionality added, in 
some form.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Struts 2.0.4 Quality

[David H. DeWolf]

   [ ] Leave at test build
   [ ] Alpha
   [X] Beta
   [ ] General Availability (GA)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fast ValueStack

[David H. DeWolf]

Nice, that seems in line with what I'm seeing as well now.  I still 
think this is worth improving, as those 5ms can add up on larger forms.


Tom Schneider wrote:

Well, I guess I was feeling more ambitious than I thought.

I wrote a simple junit test (below) that tests the 2 techniques for 
retrieving I18N text.  My numbers for 100 iterations were:

Using OGNL expression: 476 ms
Explicitly calling getText: 0 ms

Yikes!!! There is quite a difference between the two.  The OGNL version 
takes 5 ms/request compared to almost nothing for the explicit call.  It 
looks like it would be very beneficial to reimplement the UIBean key 
lookup code based on the Text component-style of text lookup. 


Agreed.  I've created:

https://issues.apache.org/struts/browse/WW-1681


 I think
the key attribute is a much cleaner way of specifying label text anyway 
so it's good to give users an incentive to use it. :)


Tom

/ start source code **/
package example;

import java.util.Iterator;

import junit.framework.TestCase;

import com.opensymphony.xwork2.ActionSupport;
import com.opensymphony.xwork2.TextProvider;
import com.opensymphony.xwork2.util.OgnlValueStack;

public class TestOgnl extends TestCase {

   public void testOgnl() {
   TestAction action = new TestAction();
   OgnlValueStack stack = new OgnlValueStack();
   stack.push(action);
   String value = null;
   long start = System.currentTimeMillis();
   for(int i = 0; i < 100; i++) {
   value = stack.findString("getText('key')");
   }
   long end = System.currentTimeMillis();
   assertEquals("value", value);
   System.out.println((end - start));
   start = System.currentTimeMillis();
   for(int i = 0; i < 100; i++) {
   value = findString(stack, "key");
   }
   end = System.currentTimeMillis();
   System.out.println((end - start));
   assertEquals("value", value);
   }

   protected String findString(OgnlValueStack stack, String key) {
   for(Iterator iterator = stack.getRoot().iterator(); iterator
   .hasNext();) {
   Object o = iterator.next();

   if(o instanceof TextProvider) {
   TextProvider tp = (TextProvider) o;
   return tp.getText(key);
   }
   }
   return null;
   }
}

class TestAction extends ActionSupport {

   @Override
   public String getText(String arg0) {
   if("key".equals(arg0)) {
   return "value";
   }
   return null;
   }

}
/ end source code **/

Ted Husted wrote:


The tags now have a "key" attribute that can be used in place of the
getText OGNL expression.

I'd be curious to know if



runs faster than



If so, I wonder if there other places where we could eliminate common
OGNL statements by adding functionality to the tags.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fast ValueStack

[David H. DeWolf]

Tom Schneider wrote:



The other thing to check is to make sure devmode is off.  With devmode 
on, the resource bundles will be reloaded quite offend vs. not being 
reload at all with devmode off.  That could definitely be a culprit if 
the getText calls are taking so long.




Apparently there's an additional property, struts.i18n.reload, that also 
will turn that feature on.  Even if devmode is off, if set to true, it 
will reload each request.  After finding that and switching to off, I'm 
back down under 200 ms.


[EMAIL PROTECTED]

The tweaks to the OGNL stack do seem to make a bit of difference, but 
more in line with the few ms here or there that you'd expect.



David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fast ValueStack

[David H. DeWolf]

Tom Schneider wrote:

David,
See https://issues.apache.org/struts/browse/WW-1661
and
http://wiki.opensymphony.com/display/WW/Performance+Tuning (particularly 
the

freemarker entries)

By just adding the freemarker.properties and copying all the templates to
the webapp directory we were able to resolve all of our freemarker
performance issues.  (or at least get the page render times down to a point
where they weren't an issue for us)


Unfortunately, I've tried both the props and copying the templates and 
am still having the issues.  I assume the big prop you're talking about 
is template_update_delay.  Any others you found useful for performance?


We were using the simple theme, so most of our text output uses the ww:text
tag--we did not have to use %{getText(...)} at all in our JSP's.  I'm not
sure if it's doing the same thing under the hood, but you might want to
experiment with that.  I would say, make the freemarker changes, then see
what kind of times you are getting.  We were able to get all our pages to
render in about 50-150 ms.  (about 100-200 ms total page load time)
Originally we were seeing about 150-300+ ms render time for the pages.
(without the caching, the numbers were much more sporadic)


Thanks for the tip. I'm using the xhtml theme and will do some 
benchmarking between the two.  I've looked further into the method 
invocation/getText issue and I think it's real, though I'm wondering why 
it hasn't been reported before considering how significant it is.


The 50-150/100-200 ms times are exactly what I'm looking for.  I'm 
currently seeing 1200-2400 when I have 15-20 form fields using getText. 
 As soon as I take out the method invocations and use the optomized 
OGNL stack, I drop down to 300.



Thanks for the help!

David


Tom

On 1/26/07, David H. DeWolf <[EMAIL PROTECTED]> wrote:


Well, I hope I'm wrong, and have only done some initial tests so far,
but it seems to me that there are two major issues causing our
slugishness.   The first seems to be OGNL and the second seems to be
freemarker templates.

By simply replacing the default value stack with the version Bob posted,
I realized a gain of about 100-200ms per request on some fairly simple
pages.   The real kicker is when I remove the method invocations
(%{getText('')})  - this results in a 1100-1200ms/request gain (an
average of about 100ms per method invocation) and drops my total request
time to well under a second.

That's why I'm thinking about looking at method processing.

What did you find to be your culprit?  Anything ww/struts related?

David


Tom Schneider wrote:
> Hey David,
> Are you finding the existing ValueStack to be impacting performance?  I
> recently wrapped up a week of tweaking our webwork app and I did some
> testing of the OGNL expressions and that was definitely not where our
> performance issues were.  If OGNL is an issue for you, I'd be 
curious to

> know how you are using OGNL and maybe try and figure why it's not
> performing
> well for you.  (Based on a conversation with Phil, I confirmed that 
OGNL

> expressions where being cached at a JVM level in xwork--so most of the
> expressions should be running as compiled expressions)  For example, if
you
> could come up with some example code that you can share with us that
> performs poorly with the existing OGNL implementation.
>
> As far as other options, Jesse (from Tapestry) has created some patches
for
> OGNL that should definitely improve the performance.  Checkout
> http://forums.opensymphony.com/thread.jspa?threadID=59785&tstart=-1 for
> details.  We're working on getting the OGNL project up and running 
again

so
> at some point these should make it into a future release.
> Tom
>
> On 1/26/07, David H. DeWolf <[EMAIL PROTECTED]> wrote:
>>
>> I'm going to be looking into optimizing the performance of the
>> ValueStack and because of the recent conversations regarding OGNL and
>> other options, I anticipate that others may have some ideas.
>>
>> I've ripped off the custom stack that Bob posted to the list a couple
of
>> a weeks ago, and have realized significant gains using it, however,
>> because it only optimizes simple properties, I still think there's a
lot
>> of room for improvement. Specifically, method invocations are very
>> expensive and happen to be used often in processing the components -
>> especially if you use i18n features (getText()), etc...
>>
>> I think I'm going to start by looking at MVEL, what other ideas do
>> people have?
>>
>>
>> David
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional comm

Re: Fast ValueStack

[David H. DeWolf]

Well, I hope I'm wrong, and have only done some initial tests so far, 
but it seems to me that there are two major issues causing our 
slugishness.   The first seems to be OGNL and the second seems to be 
freemarker templates.


By simply replacing the default value stack with the version Bob posted, 
I realized a gain of about 100-200ms per request on some fairly simple 
pages.   The real kicker is when I remove the method invocations 
(%{getText('')})  - this results in a 1100-1200ms/request gain (an 
average of about 100ms per method invocation) and drops my total request 
time to well under a second.


That's why I'm thinking about looking at method processing.

What did you find to be your culprit?  Anything ww/struts related?

David


Tom Schneider wrote:

Hey David,
Are you finding the existing ValueStack to be impacting performance?  I
recently wrapped up a week of tweaking our webwork app and I did some
testing of the OGNL expressions and that was definitely not where our
performance issues were.  If OGNL is an issue for you, I'd be curious to
know how you are using OGNL and maybe try and figure why it's not 
performing

well for you.  (Based on a conversation with Phil, I confirmed that OGNL
expressions where being cached at a JVM level in xwork--so most of the
expressions should be running as compiled expressions)  For example, if you
could come up with some example code that you can share with us that
performs poorly with the existing OGNL implementation.

As far as other options, Jesse (from Tapestry) has created some patches for
OGNL that should definitely improve the performance.  Checkout
http://forums.opensymphony.com/thread.jspa?threadID=59785&tstart=-1 for
details.  We're working on getting the OGNL project up and running again so
at some point these should make it into a future release.
Tom

On 1/26/07, David H. DeWolf <[EMAIL PROTECTED]> wrote:


I'm going to be looking into optimizing the performance of the
ValueStack and because of the recent conversations regarding OGNL and
other options, I anticipate that others may have some ideas.

I've ripped off the custom stack that Bob posted to the list a couple of
a weeks ago, and have realized significant gains using it, however,
because it only optimizes simple properties, I still think there's a lot
of room for improvement. Specifically, method invocations are very
expensive and happen to be used often in processing the components -
especially if you use i18n features (getText()), etc...

I think I'm going to start by looking at MVEL, what other ideas do
people have?


David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Fast ValueStack

[David H. DeWolf]

I'm going to be looking into optimizing the performance of the 
ValueStack and because of the recent conversations regarding OGNL and 
other options, I anticipate that others may have some ideas.


I've ripped off the custom stack that Bob posted to the list a couple of 
a weeks ago, and have realized significant gains using it, however, 
because it only optimizes simple properties, I still think there's a lot 
of room for improvement. Specifically, method invocations are very 
expensive and happen to be used often in processing the components - 
especially if you use i18n features (getText()), etc...


I think I'm going to start by looking at MVEL, what other ideas do 
people have?



David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[java-templates-plugin] TagSerializer vs TagHandler

[David H. DeWolf]

In the sandbox's java templates plugin:

What is the intention of the TagSerializer interface?  It looks as 
though if XHTMLTagSerializer is simply modified to implement TagHandler 
instead it can safely be removed.  Is there an intention that's not yet 
shown in the code, or is this a left over remnant?


Thanks,


David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Struts Annotations 1.0.0

[David H. DeWolf]

+1 Worked for me

Wendy Smoak wrote:

Struts Annotations 1.0.0 has been tagged and is available for testing
in the following Maven repository:

 http://people.apache.org/builds/struts/struts-annotations-1.0.0/m2-staging-repository/ 



To test this build, temporarily add a repository to pom.xml or
settings.xml, and change the struts-annotations dependency version
number in the Struts2 build to "1.0.0".


struts-annotations-100-staging
Struts Annotations 1.0.0 Staging Repository
http://people.apache.org/builds/struts/struts-annotations-1.0.0/m2-staging-repository/ 




This is a build-time dependency for Struts 2, and there is no
distribution assembly, though source and javadoc jars are available in
the Maven repo.

Once you have had a chance to test this build, please vote on whether
to release it to the central Maven repository.

Thank you,


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Struts Annotations 1.0.0

[David H. DeWolf]

It should also be fairly easy to determine which version is required by 
a specific struts version by looking at the version declared in the pom.


David

Don Brown wrote:
The struts annotations jar is currently only used in Struts 2 core, but 
that doesn't have to be the case.  In fact, we hope to use it in plugins 
inside and outside the Struts project, and it is certainly applicable to 
Struts 1 if it chose to use it.  This is why it gets its own version 
number and uses the original package tree.


Don

Paul Benedict wrote:
Why isn't this considered version 2.0.3? We had a similar problem back 
in 1.x when we tried to do the whole independent Struts packaging at 
different version numbers. It was quickly apparent that there was no 
way to easily know which package was compatible with another package.


Also I noticed the package structure for Struts annotation is 
org.apache.struts, not org.apache.struts2, which does not appear 
correct -- especially since it is a Struts 2 dependency.


Any points here valid? Or have I totally missed the ball?

Thanks,
Paul

Don Brown wrote:

Worked great for me, +1

Don

Wendy Smoak wrote:

Struts Annotations 1.0.0 has been tagged and is available for testing
in the following Maven repository:

 http://people.apache.org/builds/struts/struts-annotations-1.0.0/m2-staging-repository/ 



To test this build, temporarily add a repository to pom.xml or
settings.xml, and change the struts-annotations dependency version
number in the Struts2 build to "1.0.0".


struts-annotations-100-staging
Struts Annotations 1.0.0 Staging Repository
http://people.apache.org/builds/struts/struts-annotations-1.0.0/m2-staging-repository/ 




This is a build-time dependency for Struts 2, and there is no
distribution assembly, though source and javadoc jars are available in
the Maven repo.

Once you have had a chance to test this build, please vote on whether
to release it to the central Maven repository.

Thank you,



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [tiles2] Tiles TLP next steps

[David H. DeWolf]

My initial thought was that we wouldn't need the duplicate tiles2
directory (tiles/trunk would suffice). I would think that a simple parent
pom would suffice for tiles and we may not need a parent and a master.

I don't really care either way. . .that was just my first thought. We
can always move things around later if needed.

David

Wendy Smoak wrote:

On 1/14/07, Martin Cooper <[EMAIL PROTECTED]> wrote:


How about moving
> https://svn.apache.org/repos/asf/struts/sandbox/trunk/tiles/ to
> https://svn.apache.org/repos/asf/tiles/tiles2/trunk ?


Is there a need for the extra tiles2 directory in there? Why not just
...asf/tiles/trunk?


I was thinking there would be a sibling tiles/maven/trunk directory
for a master pom, but that's just because every other project I work
on has sub-projects.  Then again, we might want tiles/sandbox.
Thoughts?




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Tiles2] JSTL functions for Tiles taglib?

[David H. DeWolf]

Joe Germuska wrote:


It still seems kind of verbose.  How do people feel about using JSTL
functions?  I personally have really found them a good element in the
toolkit, but I haven't seen many open source projects include them 
alongside

custom tags.

I think this below is mich nicer:



The problem with this is that it functions have to be defined as static
methods, so the above wouldn't work directly; it would have to be something
more like


so that the static method could look up the ComponentContext.


I agree that we need to work on simplifying the tags, but I'm not sure 
whether or not functions are the way to go.  Functions to me are more 
utilities, and the fact that they're more complex, as you pointed out, 
to use for anything more than that makes me think that we'd be choosing 
the wrong tool for the job.  I'd like to keep the tags as easy as 
possible for the end user to understand, they shouldn't need to wory 
about the pageContext unless they're embeding tiles into another 
framework or doing something more than the typical.


Couldn't we just improve our tags; add additional ones, simplify the 
ones we have, etc. . .?



Does anyone think this is even worth pursuing?  It would be kind of nice if
the static TilesFunctions class could get a hold of a ThreadLocal or
something, but if Tiles is to be stand alone, I'm not sure I can think of
any reliable way to initialize a ThreadLocal before the functions might be
called.



Yes, I think it's worth pursuing a solution to the "verbose" problem. 
I'm just not convinced on the solution being functions (but I'm not 
against it necessarily either).


-D

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Tiles2] JSTL functions for Tiles taglib?

[David H. DeWolf]

Joe Germuska wrote:
Sorry, I suppose that was kind of hasty of me.  


I urged you to do it too. . .the great thing about source control is 
that we can always roll back :)


But I have to say that I

totally disagree that the behavior of the tiles:attribute tag as it is
written is defining anything.  It is causing content to appear in the page,
and therefore should have a name like insertXXX


Agree.  I don't think most people will understand conceptually the 
theoretical difference between rendering and attribute vs. rendering a 
def/template.  I think anything that renders/inserts, should be named that.




I think there was some kind of mistake, because the Javadoc was at odds 
with

the code -- it didn't describe what was actually happening, as discussed
above in this thread.

I think we should have more discussion before reverting anything, because I
feel pretty strongly about naming, and I feel like what is there now is
substantially more clear than what was there before.


Agree.



But I do apologize for my haste.

Joe


On 1/12/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote:


David H. DeWolf ha scritto:
> 2) rename tiles:put to tiles:putAttribute

I don't know, if you rename  you should rename also the 
element in the Tiles configuration file, they should be the same.

Antonio

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Tiles2] JSTL functions for Tiles taglib?

[David H. DeWolf]

Have at it, it's the best way to get back up to speed :)

If you need, ping me with questions. . .

David

Joe Germuska wrote:

On 1/11/07, David H. DeWolf <[EMAIL PROTECTED]> wrote:


BTW, I think what we though tiles:attribute would be, is actually
tiles:put and tiles:putList.  You'd think that I'd remember that.

I'd propose we:

1) rename tiles:attribute to tiles:insertAttribute



+1

2) rename tiles:put to tiles:putAttribute


I don't really like the sounds of tiles:putAttributeList, and since it
has nested putAttribute elements in it, I'm ok with leaving it alone.
Either way is ok with me.



I've never had a use case for tiles:putList, so I am agnostic about this.

I can make these changes, although I'm not totally up to speed on Tiles
development, the move to TLP, etc; if someone who has been more active 
wants

to do it, I'll gladly defer.

Joe


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Tiles2] JSTL functions for Tiles taglib?

[David H. DeWolf]

BTW, I think what we though tiles:attribute would be, is actually 
tiles:put and tiles:putList.  You'd think that I'd remember that.


I'd propose we:

1) rename tiles:attribute to tiles:insertAttribute
2) rename tiles:put to tiles:putAttribute

I don't really like the sounds of tiles:putAttributeList, and since it 
has nested putAttribute elements in it, I'm ok with leaving it alone. 
Either way is ok with me.



David

David H. DeWolf wrote:
that's what I would have thought too :), I think we definately need a 
rename.  I was looking for the insertAttribute tag in the tld when I found:


attribute
  org.apache.tiles.taglib.AttributeTag
  JSP
  
  

Re: [Tiles2] JSTL functions for Tiles taglib?

[David H. DeWolf]

that's what I would have thought too :), I think we definately need a 
rename.  I was looking for the insertAttribute tag in the tld when I found:


attribute
  org.apache.tiles.taglib.AttributeTag
  JSP
  
  

Re: [Tiles2] JSTL functions for Tiles taglib?

[David H. DeWolf]

Joe Germuska wrote:

On 1/11/07, Greg Reddin <[EMAIL PROTECTED]> wrote:


Could you not just use:





Nope.  "According to the TLD or the tag file, attribute template is
mandatory for tag insertTemplate"

And the value of template is passed straight on through to a
RequestDispatcher...


have you tried:
 

This is a little misleading, since it doesn't follow the insertXXX 
convention, but I think it will work.  Perhaps we should rename it.


David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] Time for Struts 2.1.x ? (was Re: [proposal] Tag reorganization)

[David H. DeWolf]

Ted Husted wrote:

I'd be happy to roll Struts 2.0.3 as soon as there's a new XWork 2.

Then perhaps we should dub the head 2.1.x for the Ajax tag
reorganization, since there will be backward compatibility concerns.


+1



I do wonder if we should bring up Don's Java template plugin 


+1

from the
sandbox, and utilize Bob's improved ValueStack, 


Does the improved ValueStack implement all of the features of Ognl, such 
as method invocation, etc. . ., or does it just implement the basics 
(property access, etc. . .)?



David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[tiles2] Re: A little help please

[David H. DeWolf]

Stone, Sam wrote:

I'm in a JSP that's NOT invoked by tiles. I'm looking for a certain
attribute and, if found, I want to do a .


That's not currently possible and it seems odd. Why do you want to use 
an attribute from a totally unrelated tile to store the name of a template?




Here is my code that works with the Sep2006 snapshot:
<%
String sTilesDefName = (String) request.getAttribute("tile_name");
TilesContext tilesContext = 
  new ServletTilesContext(session.getServletContext(), request,

response);
ComponentDefinition componentDefinition = 
  TilesUtil.getDefinition(sTilesDefName, tilesContext);
String sSpecialPage = 
  (String) componentDefinition.getAttribute("SpecialPage");

boolean hasCodePage = sSpecialPage!= null && sSpecialPage.length() > 0;
%>

  

  
  

  



The code from september is inconsequential at this point.  That was 
merely a snapshot and things have changed dramatically since then.  The 
point of the refactoring was to encapsulate all of the tiles processing 
logic into a container so that it could be more easily integrated and 
extended by/with other frameworks.


I'm sure there's another way to accomplish what you're trying to 
accomplish though.  So explain it a little more for me.


1) Where does the special page currently get set - in your tiles xml or 
programatically?


2) Is there are reason why you don't invoke a single definition which 
contains this logic (and then have it perform the view logic needed?)


3) Have you considered using a ViewPreparer with your definition to 
mutate the component context prior to rendering?


I'd probably go with #3 as it's cleaner:


   


public class MyViewPreparer implements ViewPreparer {

public void execute(TilesRequestContext tilesContext,
ComponentContext componentContext)
throws Exception {
if(componentContext.getAttribute("special") != null)) {
// override the default
componentContext.putAttribute(. . .)
}
}
}

Hope that helps,


David




This is all working fine. I just can't quite figure out how to do this
with the new Tiles 2 codebase.

Sam

 
-----Original Message-

From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H.
DeWolf
Sent: Tuesday, January 02, 2007 7:24 PM
To: Struts Developers List
Subject: Re: A little help please

The component context is not used to retrieve attributes for a given 
definition - it is used to define and retrieve information about the 
currently executing environment.


If you need to MODIFY a definition you can try to utilize the 
MutableTilesContainer interface.


Perhaps what you're asking for is not supported. . .what is the use 
case?  What specifically are you trying to accomplish by accessing the 
definition's attribute?



David

Stone, Sam wrote:

Still having trouble grabbing an attribute from a tiles definition. I
was doing this OK with Sep 06 code like so:

String sTilesDefName = (String) request.getAttribute("tile_name");
TilesContext tilesContext = new
  ServletTilesContext(session.getServletContext(), request, response);

ComponentDefinition componentDefinition =
  TilesUtil.getDefinition(sTilesDefName, tilesContext);

String sMyAtribute = (String)
 componentDefinition.getAttribute("myAttribute");

String sTilesDefName = (String)   
  request.getAttribute(RovingNavServlet.ATTR_ACTIVEPAGE);



David DeWolfe suggested I try the following:


TilesContainer container = TilesAccess.getContainer(context);
ComponentContext ctx = container.getComponentContext(req, res);
ComponentAttribute attr = ctx.getAttribute(name);

I did this but I find that attr is always null. Containter and ctx
appear to be valid objects.

So I modified my code a bit including checking to see if the container
was really recognizing my definition (isValidDefinition). It is. If I
give the name of any existing definition then it returns true. If I

give

it a name not in my tiles-defs then it returns false.

Ctx.getAttributeNames is coming back with no attributes (i.e. my while
(it.hasNext()) loop never executes). So I'm still stuck.

Following is my current code:

try
{
TilesContainer container = 
  TilesAccess.getContainer(session.getServletContext());


String sTilesDefName = (String) request.getAttribute("tile_name");
if (container.isValidDefinition(request, response, sTilesDefName))
System.out.println("valid definition");
else
System.out.println("invalid definition");

ComponentContext ctx = container.getComponentContext(pageContext);
System.out.println("->ctx=" + ctx);

Iterator it = ctx.getAttributeNames();
int i=0;
while (it.hasNext())
System.out.println("->" + i++);
}
catch (Exception e)
{
System.out.println(e);
}

 
Sam



--

Re: A little help please

[David H. DeWolf]

The component context is not used to retrieve attributes for a given 
definition - it is used to define and retrieve information about the 
currently executing environment.


If you need to MODIFY a definition you can try to utilize the 
MutableTilesContainer interface.


Perhaps what you're asking for is not supported. . .what is the use 
case?  What specifically are you trying to accomplish by accessing the 
definition's attribute?



David

Stone, Sam wrote:

Still having trouble grabbing an attribute from a tiles definition. I
was doing this OK with Sep 06 code like so:

String sTilesDefName = (String) request.getAttribute("tile_name");
TilesContext tilesContext = new
  ServletTilesContext(session.getServletContext(), request, response);

ComponentDefinition componentDefinition =
  TilesUtil.getDefinition(sTilesDefName, tilesContext);

String sMyAtribute = (String)
 componentDefinition.getAttribute("myAttribute");

String sTilesDefName = (String)   
  request.getAttribute(RovingNavServlet.ATTR_ACTIVEPAGE);



David DeWolfe suggested I try the following:


TilesContainer container = TilesAccess.getContainer(context);
ComponentContext ctx = container.getComponentContext(req, res);
ComponentAttribute attr = ctx.getAttribute(name);


I did this but I find that attr is always null. Containter and ctx
appear to be valid objects.

So I modified my code a bit including checking to see if the container
was really recognizing my definition (isValidDefinition). It is. If I
give the name of any existing definition then it returns true. If I give
it a name not in my tiles-defs then it returns false.

Ctx.getAttributeNames is coming back with no attributes (i.e. my while
(it.hasNext()) loop never executes). So I'm still stuck.

Following is my current code:

try
{
TilesContainer container = 
  TilesAccess.getContainer(session.getServletContext());


String sTilesDefName = (String) request.getAttribute("tile_name");
if (container.isValidDefinition(request, response, sTilesDefName))
System.out.println("valid definition");
else
System.out.println("invalid definition");

ComponentContext ctx = container.getComponentContext(pageContext);
System.out.println("->ctx=" + ctx);

Iterator it = ctx.getAttributeNames();
int i=0;
while (it.hasNext())
System.out.println("->" + i++);
}
catch (Exception e)
{
System.out.println(e);
}

 
Sam



-Original Message-
From: Stone, Sam [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 02, 2007 1:28 PM

To: Struts Developers List
Subject: RE: How to access componentDefinition?

In your example:

TilesContainer container = TilesAccess.getContainer(context);
ComponentContext ctx = container.getComponentContext(req, res);
ComponentAttribute attr = ctx.getAttribute(name);

ctx comes back with no attributes (therefore attr results in null).

I think I want to call getContainer with pageContext. How do I get the
pageContext?

To recap what I WAS doing with the old API - I was inspecting a tiles
definition and searching for a specific attribute. I'm doing this BEFORE
dispatching to the tiles servlet.

Sam

-Original Message-
From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H.
DeWolf
Sent: Tuesday, January 02, 2007 10:36 AM
To: Struts Developers List
Subject: Re: How to access componentDefinition?

potentially . . .it depends on your environment.  My guess is that from 
your example the answer is yes.


David

Stone, Sam wrote:

TilesContainer container = TilesAccess.getContainer(context);

Is "context" the servletContext?

-Original Message-
From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H.
DeWolf
Sent: Tuesday, January 02, 2007 10:30 AM
To: Struts Developers List
Subject: Re: How to access componentDefinition?

Hi Sam:

Everything is now done through the container.

Try something like this:

TilesContainer container = TilesAccess.getContainer(context);
ComponentContext ctx = container.getComponentContext(req, res);
ComponentAttribute attr = ctx.getAttribute(name);


David

Stone, Sam wrote:

Using the API from Sep 2006 I was able to access externally an

attribute

from a tiles definition as follows:

String sTilesDefName = (String) request.getAttribute("tile_name");
TilesContext tilesContext = new
ServletTilesContext(session.getServletContext(), request, response);

ComponentDefinition componentDefinition =
TilesUtil.getDefinition(sTilesDefName, tilesContext);

String sMyAtribute = (String)
componentDefinition.getAttribute("myAttribute");

I can't quite figure out how to do this using the current Tiles 2

API.

Sam



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--

Re: How to access componentDefinition?

[David H. DeWolf]

potentially . . .it depends on your environment.  My guess is that from 
your example the answer is yes.


David

Stone, Sam wrote:

TilesContainer container = TilesAccess.getContainer(context);

Is "context" the servletContext?

-Original Message-----
From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H.
DeWolf
Sent: Tuesday, January 02, 2007 10:30 AM
To: Struts Developers List
Subject: Re: How to access componentDefinition?

Hi Sam:

Everything is now done through the container.

Try something like this:

TilesContainer container = TilesAccess.getContainer(context);
ComponentContext ctx = container.getComponentContext(req, res);
ComponentAttribute attr = ctx.getAttribute(name);


David

Stone, Sam wrote:

Using the API from Sep 2006 I was able to access externally an

attribute

from a tiles definition as follows:

String sTilesDefName = (String) request.getAttribute("tile_name");
TilesContext tilesContext = new
ServletTilesContext(session.getServletContext(), request, response);

ComponentDefinition componentDefinition =
TilesUtil.getDefinition(sTilesDefName, tilesContext);

String sMyAtribute = (String)
componentDefinition.getAttribute("myAttribute");

I can't quite figure out how to do this using the current Tiles 2 API.

Sam



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to access componentDefinition?

[David H. DeWolf]

Hi Sam:

Everything is now done through the container.

Try something like this:

TilesContainer container = TilesAccess.getContainer(context);
ComponentContext ctx = container.getComponentContext(req, res);
ComponentAttribute attr = ctx.getAttribute(name);


David

Stone, Sam wrote:

Using the API from Sep 2006 I was able to access externally an attribute
from a tiles definition as follows:

String sTilesDefName = (String) request.getAttribute("tile_name");
TilesContext tilesContext = new
ServletTilesContext(session.getServletContext(), request, response);

ComponentDefinition componentDefinition =
TilesUtil.getDefinition(sTilesDefName, tilesContext);

String sMyAtribute = (String)
componentDefinition.getAttribute("myAttribute");

I can't quite figure out how to do this using the current Tiles 2 API.

Sam



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [proposal] Tag reorganization

[David H. DeWolf]

That's what I'm imagining too. . .and we're agreeing that this 
incompatibility is a pill we have to swallow.


Ian Roughley wrote:
I think I am missing something here - how will the tags be invoked?  It 
will need to be a new tld with a new name space, right?  Something like 
 rather than  - so there 
will be a compatibility issue, but all the functionality will be moved 
forward.


/Ian


David H. DeWolf wrote:



Ted Husted wrote:

Don mentioned a separate tag library, so that would indicate another
prefix, but there'd be no reason why the internal tag syntax would
change.

To keep the codebase manageable, I believe we do need to make this
change, and I'd rather make it now while we are in our first beta
series than after the first Struts 2 GA. The plugin model might also
open the door to other AJAX implementations of the same tags.


I agree.  I like it, but just wanted to make sure we think through the 
compatibility changes before we make a decision.


In essence we're saying that this change is more important than 
backwards compat of this one tag and we're willing to live with those 
repercussions.   I'm on board with that.





-T.

On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:

Ok, as long as we keep the tag prefixes and tag names once they are
abstracted from the plugin.

At one point we talked about having a simple version which is extended
by the dojo version and added additional (dojo-specific) featuers.  It
seems like the current names would be more likely be used for the core
tags - not the dojo-enhanced ones.

Ted Husted wrote:
> A struts-dojo plugin shouldn't change the tag syntax. It should just
> be a matter of adding the JAR, as we do for Spring, and 
JasperReports,

> and Tiles, so forth.
>
> On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:
>> Nope, that's the one I'm talking about.  I got the impression we 
were
>> going to keep it as is and thus break backwards compatibility in 
2.0.2

>> -- and then mess with it again it when we create the plugin. . .
>>
>> David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [proposal] Tag reorganization

[David H. DeWolf]

Ted Husted wrote:

Don mentioned a separate tag library, so that would indicate another
prefix, but there'd be no reason why the internal tag syntax would
change.

To keep the codebase manageable, I believe we do need to make this
change, and I'd rather make it now while we are in our first beta
series than after the first Struts 2 GA. The plugin model might also
open the door to other AJAX implementations of the same tags.


I agree.  I like it, but just wanted to make sure we think through the 
compatibility changes before we make a decision.


In essence we're saying that this change is more important than 
backwards compat of this one tag and we're willing to live with those 
repercussions.   I'm on board with that.





-T.

On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:

Ok, as long as we keep the tag prefixes and tag names once they are
abstracted from the plugin.

At one point we talked about having a simple version which is extended
by the dojo version and added additional (dojo-specific) featuers.  It
seems like the current names would be more likely be used for the core
tags - not the dojo-enhanced ones.

Ted Husted wrote:
> A struts-dojo plugin shouldn't change the tag syntax. It should just
> be a matter of adding the JAR, as we do for Spring, and JasperReports,
> and Tiles, so forth.
>
> On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:
>> Nope, that's the one I'm talking about.  I got the impression we were
>> going to keep it as is and thus break backwards compatibility in 2.0.2
>> -- and then mess with it again it when we create the plugin. . .
>>
>> David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [proposal] Tag reorganization

[David H. DeWolf]

Ok, as long as we keep the tag prefixes and tag names once they are 
abstracted from the plugin.


At one point we talked about having a simple version which is extended 
by the dojo version and added additional (dojo-specific) featuers.  It 
seems like the current names would be more likely be used for the core 
tags - not the dojo-enhanced ones.


Ted Husted wrote:

A struts-dojo plugin shouldn't change the tag syntax. It should just
be a matter of adding the JAR, as we do for Spring, and JasperReports,
and Tiles, so forth.

On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:

Nope, that's the one I'm talking about.  I got the impression we were
going to keep it as is and thus break backwards compatibility in 2.0.2
-- and then mess with it again it when we create the plugin. . .

David


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [proposal] Tag reorganization

[David H. DeWolf]

Nope, that's the one I'm talking about.  I got the impression we were 
going to keep it as is and thus break backwards compatibility in 2.0.2 
-- and then mess with it again it when we create the plugin. . .


David

Don Brown wrote:
The only currently broken tag, in terms of 2.0.1 compatibility, is the 
date picker tag.  It has been reimplemented and renamed.  Am I missing any?


Don

David H. DeWolf wrote:
Unless I'm missing something, that would mean we break backwards 
compatibility between 2.0.1 and 2.0.2 and then force another break 
between 2.0.2 and 2.0.3, right? I want to get 2.0.2 out as well, but 
that doesn't sound like a good idea to me.


Why not roll back the tags to 2.0.1 compatibility and then release?

David

Ted Husted wrote:

On 12/27/06, Don Brown <[EMAIL PROTECTED]> wrote:
I'd like to move on this quickly and have it completed within two 
weeks.


Thoughts?


Do we want to release Struts 2.0.2 with what we have already?

A Struts 2.0.3 is already a foregone conclusion since XWork 2 is at RC1.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [proposal] Tag reorganization

[David H. DeWolf]

Unless I'm missing something, that would mean we break backwards 
compatibility between 2.0.1 and 2.0.2 and then force another break 
between 2.0.2 and 2.0.3, right? I want to get 2.0.2 out as well, but 
that doesn't sound like a good idea to me.


Why not roll back the tags to 2.0.1 compatibility and then release?

David

Ted Husted wrote:

On 12/27/06, Don Brown <[EMAIL PROTECTED]> wrote:

I'd like to move on this quickly and have it completed within two weeks.

Thoughts?


Do we want to release Struts 2.0.2 with what we have already?

A Struts 2.0.3 is already a foregone conclusion since XWork 2 is at RC1.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Struts 2.0.2 status

[David H. DeWolf]

Ted Husted wrote:

Both the datetimepicker and the action-redirect prefix worked in the
2.0.1 beta but don't work now.  Both are outright bugs,  and it's
unlikely we would get positive votes for a build with know defects.

AFAIK, the JavaScript error (WW-1559) doesn't impede functionality. It
might keep people from voting GA, but with the XWork RC dependency,
that's not going to happen anyway.


Ahh, ok, you misunderstood me. What I'm saying is that I think it DOES 
impede functionality.  It's a bug that was not present in 2.0.1 (AFAIK) 
but is now.  The js error prevents the submission of values from occuring.


-Ted.

On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:

That's fine with me, just help me understand the difference between this
and the datetimepicker and action-redirect issues. . .what makes them
showstoppers?

not trying to be a pain, just trying to understand :)

David

Ted Husted wrote:
> The problem is that we have a an issue report, but no suggestions as
> to a resolution. If we have a patch to apply for 2.0.2, that would be
> great. But, otherwise, we might want to keep it as a known issue to
> fix as soon as we figure out how.  A 2.0.2 release is not going to a a
> GA candidate anyway since XWork 2 is only at RC1.
>
> -Ted.
>
> On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:
>> After some more testing, it appears as though the javascript issues
>> associated with the optiontransferselect (WW-1559) are actually
>> effecting it's behavior.  I think we should add this back to the 2.0.2
>> list.
>>
>> I'm not all that familiar with dojo, but I'll start to look into it
>> today.
>>
>> David
>>
>> Ted Husted wrote:
>> > We're down to a handful of problems, which are all reflected in the
>> > Showcase examples, one way or the other. Some of these were also
>> > present in Struts 2.0.1, and so may be a problem with the example
>> > itself.
>> >
>> > * https://issues.apache.org/struts/browse/WW-1538
>> >
>> > The showstoppers are the action-redirect prefix and the datetime
>> picker.
>> >
>> > If we were down to one or the other, I'd be tempted to roll 2.0.2,
>> > just for fun, but two non-functioning features seems a bit much --
>> > when we usually shoot for zero. :)
>> >
>> > -Ted.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Struts 2.0.2 status

[David H. DeWolf]

That's fine with me, just help me understand the difference between this 
and the datetimepicker and action-redirect issues. . .what makes them 
showstoppers?


not trying to be a pain, just trying to understand :)

David

Ted Husted wrote:

The problem is that we have a an issue report, but no suggestions as
to a resolution. If we have a patch to apply for 2.0.2, that would be
great. But, otherwise, we might want to keep it as a known issue to
fix as soon as we figure out how.  A 2.0.2 release is not going to a a
GA candidate anyway since XWork 2 is only at RC1.

-Ted.

On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:

After some more testing, it appears as though the javascript issues
associated with the optiontransferselect (WW-1559) are actually
effecting it's behavior.  I think we should add this back to the 2.0.2 
list.


I'm not all that familiar with dojo, but I'll start to look into it 
today.


David

Ted Husted wrote:
> We're down to a handful of problems, which are all reflected in the
> Showcase examples, one way or the other. Some of these were also
> present in Struts 2.0.1, and so may be a problem with the example
> itself.
>
> * https://issues.apache.org/struts/browse/WW-1538
>
> The showstoppers are the action-redirect prefix and the datetime 
picker.

>
> If we were down to one or the other, I'd be tempted to roll 2.0.2,
> just for fun, but two non-functioning features seems a bit much --
> when we usually shoot for zero. :)
>
> -Ted.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Struts 2.0.2 status

[David H. DeWolf]

After some more testing, it appears as though the javascript issues 
associated with the optiontransferselect (WW-1559) are actually 
effecting it's behavior.  I think we should add this back to the 2.0.2 list.


I'm not all that familiar with dojo, but I'll start to look into it today.

David

Ted Husted wrote:

We're down to a handful of problems, which are all reflected in the
Showcase examples, one way or the other. Some of these were also
present in Struts 2.0.1, and so may be a problem with the example
itself.

* https://issues.apache.org/struts/browse/WW-1538

The showstoppers are the action-redirect prefix and the datetime picker.

If we were down to one or the other, I'd be tempted to roll 2.0.2,
just for fun, but two non-functioning features seems a bit much --
when we usually shoot for zero. :)

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [FWD: Re: [tiles2] Tiles TLP next steps]

[David H. DeWolf]

Greg Reddin wrote:


> Subject: Re: [tiles2] Tiles TLP next steps
> From: "David H. DeWolf" <[EMAIL PROTECTED]>
>
> True.  Good point.  I'm ok with either, but my preference would be
> confluence.




I haven't really used Confluence yet, but I hear great things about it.  
I'd

like to give it a try.

A couple of other things:

1.  Who wants to be a moderator?


I can help with that.



2.  Should we set up a TILES JIRA instance or remain part of Struts?  I
understand the issue of moving tickets has a tentative resolution.  Since
our tickets are currently SB- I think we want to move them anyway.


I'd be for staying in the Struts instance (like Shale did) until we have 
a good reason to move away from it.  It seems like it would be less 
burden on infra (and maybe ourselves).  Is there any reason why our own 
instance may be advantagous?


Merry Christmas!


David


Greg



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [tiles2] Tiles TLP next steps

[David H. DeWolf]

True.  Good point.  I'm ok with either, but my preference would be 
confluence.


David

Wendy Smoak wrote:

On 12/23/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:


Those look like good defaults to me.  The only thing I question is the
wiki - do we want to stay on cwiki (confluence) instead of moving to
moinmoin?


Looks like Tiles currently has pages on both of the Struts wikis.  The
original 'TilesTopLevel' page, plus a few more, are on MoinMoin.  The
only thing I see on Confluence is the graduation proposal.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [tiles2] Tiles TLP next steps

[David H. DeWolf]

Great, thanks for the update!

Those look like good defaults to me.  The only thing I question is the 
wiki - do we want to stay on cwiki (confluence) instead of moving to 
moinmoin?


Wendy Smoak wrote:

The board meeting minutes take a while to be approved and posted, but
Henri mentioned on the incubator list that the Tiles resolution was
approved:

http://mail-archives.apache.org/mod_mbox/incubator-general/200612.mbox/[EMAIL PROTECTED] 



I think the next thing to do is open an issue in the infrastructure
JIRA project to ask for mailing lists, svn space, etc., etc.

Here's the one for Shale:  http://issues.apache.org/jira/browse/INFRA-866

Do we want anything done differently for Tiles?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [tiles2] Re: svn commit: r488006 - in /struts/sandbox/trunk/tiles/tiles-core/src/main/java/org/apache/tiles: factory/TilesContainerFactory.java impl/BasicTilesContainer.java

[David H. DeWolf]

Ok, I think I understand the use case, and using a map is definitely 
cleaner than what I had done in the struts2 plugin - create a "wrapper" 
for the actual context which allowed me to inject my own defaults (see: 
http://svn.apache.org/repos/asf/struts/struts2/trunk/plugins/tiles/src/main/java/org/apache/struts2/tiles/ConfiguredServletContext.java)




I still think that ideally we'd only provide one of the two, but
unfortunately, we can't remove the context in lieu of the map, because 
then we won't have it to create the context factory, and the opposite 
isn't that nice either.


Also, I still wonder if what's provided in the map are really defaults, 
or if it's just a different way to provide "custom" behavior.




I don't really have any better ideas, I was just curios what your 
thoughts were. . . I'll think about it a little harder and see what I 
come up with.



David

Antonio Petrelli wrote:

David H. DeWolf ha scritto:

Antonio,

I'm not sure I understand why we need to support both the context and 
a map of defaults for retrieving config info for factories.  It seems 
redundant and thus confusing.


If we want to use a map, shouldn't we just remove the context all 
together and have the client push all of the init parameters into the 
map prior to invocation?


I made that change (the use of "custom" defaults) because some container 
"creators" (such as the TilesPlugin for Struts 1) need to have default 
classes when they are not specified explicitly.
In particular, in the TilesPlugin I am wrapping the plugin context and 
the ServletContext as a unique ServletContext (giving precedence to the 
plugin context init params).
Now, if the Struts application is configured to use modules, it will use 
the "keyed" container as a default, otherwise it will use 
BasicTilesContainer (this is what I have in mind, there is no code 
currently in the Struts-Tiles2 plugin).
So I decided to use a custom "defaults" map. I thought also to provide a 
"default" class inside the ServletContext provided by TilesPlugin, but 
the code could become a bit messy.


This was I was thinking when I made those changes, anyway if you have a 
better idea let me know.


Thank you
Antonio

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[tiles2] Re: svn commit: r488006 - in /struts/sandbox/trunk/tiles/tiles-core/src/main/java/org/apache/tiles: factory/TilesContainerFactory.java impl/BasicTilesContainer.java

[David H. DeWolf]

Antonio,

I'm not sure I understand why we need to support both the context and a 
map of defaults for retrieving config info for factories.  It seems 
redundant and thus confusing.


If we want to use a map, shouldn't we just remove the context all 
together and have the client push all of the init parameters into the 
map prior to invocation?


Thoughts?

David

[EMAIL PROTECTED] wrote:

Author: apetrelli
Date: Sun Dec 17 08:50:35 2006
New Revision: 488006

URL: http://svn.apache.org/viewvc?view=rev&rev=488006
Log:
SB-101
Refactorings to allow easier inheritance.

Modified:

struts/sandbox/trunk/tiles/tiles-core/src/main/java/org/apache/tiles/factory/TilesContainerFactory.java

struts/sandbox/trunk/tiles/tiles-core/src/main/java/org/apache/tiles/impl/BasicTilesContainer.java

Modified: 
struts/sandbox/trunk/tiles/tiles-core/src/main/java/org/apache/tiles/factory/TilesContainerFactory.java
URL: 
http://svn.apache.org/viewvc/struts/sandbox/trunk/tiles/tiles-core/src/main/java/org/apache/tiles/factory/TilesContainerFactory.java?view=diff&rev=488006&r1=488005&r2=488006
==
--- 
struts/sandbox/trunk/tiles/tiles-core/src/main/java/org/apache/tiles/factory/TilesContainerFactory.java
 (original)
+++ 
struts/sandbox/trunk/tiles/tiles-core/src/main/java/org/apache/tiles/factory/TilesContainerFactory.java
 Sun Dec 17 08:50:35 2006
@@ -93,8 +93,28 @@
  */
 public static TilesContainerFactory getFactory(Object context)
 throws TilesException {
+return getFactory(context, DEFAULTS);
+}
+
+/**
+ * Retrieve a factory instance as configured through the
+ * specified context.
+ * 
+ * The context will be queried and if a init parameter
+ * named 'org.apache.tiles.CONTAINER_FACTORY' is discovered
+ * this class will be instantiated and returned. Otherwise,
+ * the factory will attempt to utilize one of it's internal
+ * factories.
+ *
+ * @param context the executing applications context.
+ *Typically a ServletContext or PortletContext
+ * @return a tiles container
+ * @throws TilesException if an error occurs creating the factory.
+ */
+public static TilesContainerFactory getFactory(Object context,
+   Map defaults) throws TilesException {
 return (TilesContainerFactory) TilesContainerFactory
-.createFactory(context, CONTAINER_FACTORY_INIT_PARAM);
+.createFactory(context, CONTAINER_FACTORY_INIT_PARAM, defaults);
 }
 
 public TilesContainer createContainer(Object context) throws TilesException {

@@ -108,30 +128,44 @@
 
 public TilesContainer createTilesContainer(Object context)

 throws TilesException {
+return createTilesContainer(context, DEFAULTS);
+}
+
+public TilesContainer createTilesContainer(Object context,
+   Map defaults) throws TilesException {
 BasicTilesContainer container = new BasicTilesContainer();
-initializeContainer(context, container);
+initializeContainer(context, container, defaults);
 return container;
 }
 
 public MutableTilesContainer createMutableTilesContainer(Object context)

 throws TilesException {
+   return createMutableTilesContainer(context, DEFAULTS);
+}
+
+public MutableTilesContainer createMutableTilesContainer(Object context,
+   Map defaults) throws TilesException {
 CachingTilesContainer container = new CachingTilesContainer();
-initializeContainer(context, container);
+initializeContainer(context, container, defaults);
 return container;
 }
 
-public void initializeContainer(Object context,

-BasicTilesContainer container)
+protected void initializeContainer(Object context,
+BasicTilesContainer container,
+Map defaults)
 throws TilesException {
 
 TilesContextFactory contextFactory =

-(TilesContextFactory) createFactory(context, 
CONTEXT_FACTORY_INIT_PARAM);
+(TilesContextFactory) createFactory(context,
+   CONTEXT_FACTORY_INIT_PARAM, defaults);
 
 DefinitionsFactory defsFactory =

-(DefinitionsFactory) createFactory(context, 
DEFINITIONS_FACTORY_INIT_PARAM);
+(DefinitionsFactory) createFactory(context,
+   DEFINITIONS_FACTORY_INIT_PARAM, defaults);
 
 PreparerFactory prepFactory =

-(PreparerFactory) createFactory(context, 
PREPARER_FACTORY_INIT_PARAM);
+(PreparerFactory) createFactory(context,
+   PREPARER_FACTORY_INIT_PARAM, defaults);
 
 TilesApplicationContext tilesContext =

 contextFactory.createApplicationContext(context);
@@ -168,15 +202,21 @@
 }
 
 
-public static Object createFactor

Re: OGNL performance detrimental to Struts 2

[David H. DeWolf]

I double dare you :)

Don Brown wrote:

Well, I dare you then: http://issues.apache.org/struts/browse/WW-1566

:)

Don

Chris Brock wrote:

Don't dare me.  I'm pretty ambitious.  I wrote MVEL 1.0 in three days.


Don Brown-2 wrote:
 
I'd like it to be possible for a Struts developer to swap in a new 
EL, perhaps MVEL, if they didn't like OGNL for some reason.  If you 
can create a patch to make that happen, I would consider it my early 
Christmas present :)


Don

Chris Brock wrote:
   

Why do you think it would be so terribly difficult?  What does MVEL not
support that is currently supported by OGNL that would not be 
fixable by

a
few tweaks to MVEL's syntax?

Generally, MVEL's API architecture follows the same pattern as OGNL,
supports type coercion, conversion, projections, etc. 
Not to mention that MVEL is now an active project and OGNL is not, 
and of
course the performance advantage in MVEL which is only getting 
better by

the
day.


Don Brown-2 wrote:
   
If you can find a way to completely replace OGNL by MVEL, I'd be 
very interested to see it. :)


Don

Chris Brock wrote:
   
I think the problem is that the Tapestry solution is simply a 
property

accessor package, which doesn't really meet the needs of the
established
WebWork community which relies on "expressions" in addition to
properties
to
accomplish tasks.

That being said, my project (MVEL) stands willing to step in and
assist. I
think it's performance and flexibility speak for itself: 
http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language



Jessek wrote:
 

I'm still not getting all of the hand wringing that is going on in
this
thread about ognl. There is what I think a perfectly reasonable
solution
that will help finish up those last remaining bits that ognl 
needs to

really be production ready.
Despite whatever we want to call it you could theoretically view 
it as

just another interpreter. I may be from an "enemy project" but I'm
still
willing/able to make the changes necessary for this to work.
I've tried on a few occasions to engage whoever I can in the ognl
world
to
make this possible but haven't gotten any good responses yet. This
isn't
a
hard problem to solve, so it's frustrating watching everyone 
implement

new
property path interpreters /debate ognl when the answer is right
there...
;/


Don Brown wrote:
   

I wrote a simple Struts 2 TemplateEngine that renders tags in pure
Java, as opposed to the Freemarker that is used currently.  I'm
seeing
performance improvements between 3 and 4 times faster than the old
tags.  This engine is based on the design I layed out previously 
[1].

It is better suited to simple tag rendering where the Freemarker
version is better suited for HTML-heavy tag output and 
customization.


The Java engine:
 - Allows the tag generator and "interceptors" to deal with tag
objects, not pure text
 - Tag "interceptors" or handlers have full control over the output
 - Serialization of tag objects into text can be customized
 - Is fast - 3 to 4 times faster than the Freemarker engine

Anyways, if nothing else, it shows there are things we can do to
drastically speed up the tags w/o throwing out OGNL.  If you 
only use

the simple theme, this might be an attractive option that gives you
more customization and speed.

I'm kinda up in the air as to where to put this.  I'm leaning 
toward

committing it to the sandbox as then it would be clear it is
experimental, especially since not all tags and themes are
implemented.

Don

[1] - 
http://www.mail-archive.com/dev@struts.apache.org/msg25065.html


On 12/13/06, Don Brown <[EMAIL PROTECTED]> wrote:
 
Very interesting... I wonder how much of the performance hit 
was due

to
Freemarker and how much OGNL.  Could you package this 
application in

a
war and attach it to a JIRA ticket?  I'd love to have it for 
future

comparisons.

Don

dice wrote:
   

They are my stats Ted. The stats are posted below along with my
sample
  

JSP
   
code. I only tried the textfield tag but looking at the ftl 
and vm
  

files for
   
the other tags I can't see how the results would be any 
different.


Perhaps an interim solution could be to remove the use of OGNL 
from
  

core
   

functionality that doesn't require it. eg. Is it really necessary
to
  

access
   

UIBean attributes from the theme templates using OGNL?

PS: I emulated the Struts 2 themes in Struts 1 by wrapping 
Struts 1
  

tags in
   

JSP Tag files and performance was still impressive.

Re: Problems with Tiles 2 and WS 5

[David H. DeWolf]

I'll try to hit both questions

1) The answer to your first question is easy:

http://svn.apache.org/repos/asf/struts/sandbox/trunk/

2) a) yes, a lot has changed. Tiles2 is a revolution, not an evolution

   b) yes, we now require 1.5, though the plan is to provide retro 
weaver distributions.  I can't say I've tried them though


   c) TilesContext is now managed by the TilesContainer, and yes, they 
are both created by configured factories.  If you don't specify one in 
your configuration, defaults will be used.


   d) your changes look good to me

   e) if you want to try the most recent versions of the snapshots, 
they are located in the maven snapshot repo: 
http://people.apache.org/repo/m2-snapshot-repository/


   f) I believe that the log message "INFO: CONFIG FILES DEFINED IN 
WEB.XML" was removed after the container refactoring was complete, yet 
you're using the context_factory configuration that was added during 
that refactoring. . .that would lead me to believe that you're using a 
snapshot that doesn't necessarily match the binary.  Try using the 
'2.0-r480013-SNAPSHOT' version in the repo.


Let me know how it goes! Thanks for trying out the bleeding edge.


David

Stone, Sam wrote:

I got my entire app working on Websphere 5 (servlet 1.2, jsp 2.3, jdk
1.4.2) using the tiles-core-2.0-SNAPSHOT.jar from 9/14/2006 (filesize:
128880, CRC: 3F46E3BF). I did have to use jstl.jar and standard.jar (not
the 1.1.2 versions) because of this WebSphere environment.

I'd like to either:
A)  find the source code for this exact build
OR
B)  migrate to the latest Tiles 2 snapshot

For option A: can anybody help me pin down this source code?

Option B
---
I see a lot has change since Sep 2006. First and foremost is that Tiles
2 is now built on JDK 1.5. I also see that tiles:insert has become
tiles:insertDefinition and that TilesContext now is factory generated.

I am having little luck migrating and getting not much to go on
log-message-wise. This is what I've tried:

1)  changed all my tiles-defs to use tiles-config_2_0.dtd instead of
1.1
2)  changed all my tiles:insert statements to tiles:insertDefinition
3)  added the following to my web.xml:
   
org.apache.tiles.CONTEXT_FACTORY

org.apache.tiles.context.enhanced.EnhancedContextFactory
   
 
4)  retrotranslated the current tiles-core-2.0-SNAPSHOT.jar and
tiles-api-2.0-SNAPSHOT.jar and put these into my web-inf/lib directory
and removed the old jar.
5)  Retrotranslated and tossed in the current xml-apis-1.0.b2.jar as
well

None of my pages come up and I get no messages. All I see in the log is
messages to the effect that initDefinitionsFactory has started (I
think). 


INFO: CONFIG FILES DEFINED IN WEB.XML
INFO: initializing definitions factory...

When I purposely mess up a definition I get a message directing me to
the problem so I think this is working.

What steps have I missed? If the taglib included in the current jar
going to work for me?

Any advice is appreciated.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [tiles2] Multiple container/definitions factory support

[David H. DeWolf]

 . . .I was going to suggest the same thing, but you beat me to it :)

I think you may come into some problems because of how we use 
TilesAccess internally. This class should be a helpful utility for 
external applications, but not used by the guts of tiles (tags for 
instance).  My guess is that as you move forward, you'll find a need to 
refactor these places.




Antonio Petrelli wrote:

Antonio Petrelli ha scritto:
I think that the support to multiple DefinitionsFactory should be 
provided (that contradicts what I wrote some time ago), but I don't 
know if the "multiplicity" should be provided at container-level or at 
DefinitionsFactory-level.


I think I answered myself. I am going to create a new TilesContainer 
(probably extending BasicTilesContainer), and a TilesContainerFactory 
(probably extending BasicTilesContainerFactory) to allow the creation of 
more than one DefinitionsFactory, associating each one to a "key", where 
the key will be the name of the Struts module.


Ciao
Antonio

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: which jar files are needed when executing the tiles in struts2 application

[David H. DeWolf]

Unfortunately it depends on which versions you're using.  Tiles support 
in struts2 is experimental at this point.  Things should stabilize in 
2.0.2 since we will not release with a SNAPSHOT dependency, but rather a 
versioned SNAPSHOT.


It looks to me like you're using a version of struts that depends an 
older version of Tiles2 (one of the snapshots prior to the container 
refactor).  Because of that, I'd try to use: 2.0-r468346-SNAPSHOT.



David

ravikumar wrote:

when i am executing tiles2 application in the server console & in the browser 
exception like this

any one know the solution 
give me reply immediately




Thanks
Ravi

java.lang.NullPointerException
at 
org.apache.struts2.views.tiles.TilesResult.getComponentDefinition(TilesResult.java:162)
at 
org.apache.struts2.views.tiles.TilesResult.doExecute(TilesResult.java:116)
at 
org.apache.struts2.dispatcher.StrutsResultSupport.execute(StrutsResultSupport.java:175)
at 
com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:309)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:218)
at 
com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:177)
at 
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
at 
com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
at 
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
at 
com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:123)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
at 
com.opensymphony.xwork2.interceptor.ParametersInterceptor.intercept(ParametersInterceptor.java:147)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
at 
com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:105)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
at 
org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:80)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
at 
org.apache.struts2.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:204)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
at 
com.opensymphony.xwork2.interceptor.ModelDrivenInterceptor.intercept(ModelDrivenInterceptor.java:74)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
at 
com.opensymphony.xwork2.interceptor.ScopedModelDrivenInterceptor.intercept(ScopedModelDrivenInterceptor.java:120)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
at 
org.apache.struts2.interceptor.ProfilingActivationInterceptor.intercept(ProfilingActivationInterceptor.java:59)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
at 
org.apache.struts2.interceptor.debugging.DebuggingInterceptor.intercept(DebuggingInterceptor.java:174)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
at 
com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:115)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
at 
com.opensymphony.xwork2.interceptor.I18nInterceptor.intercept(I18nInterceptor.java:143)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
at 
com.opensymphony.xwork2.interceptor.PrepareInterceptor.intercept(PrepareInterceptor.java:115)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
at 
org.apache.struts2.interceptor.ServletConfigInterceptor.intercept(ServletConfigInterceptor.java:156)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:200)
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=53679&messageID=107829#107829


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--

Re: Tiles 2 jdk

[David H. DeWolf]

Please continue to ask these questions on the mailing lists so that 
everyone can benefit from the answers. . .



Stone, Sam wrote:
Before I go through the trouble of building this and portlet and 
wahtever else I might need - will it all compile with JDK 1.4? I've been 
using an older snapshot jar with WebSphere 5 (JDK 1.4.2) and I need to 
either:


No, by default they will not. However, you should be able to utilize the 
maven retrotranslator goal - which will make 1.5 code and back-port it.



a) get a new build working from the current source code OR
? I'm not sure I understand.  Are you looking for the retrotranslator 
jar to be published as a snapshot?



b) get the last source code that does work with JDK 1.4


We are not directly supporting 1.4.



Sam


-Original Message-----
From: David H. DeWolf on behalf of David H. DeWolf
Sent: Tue 12/12/2006 6:25 PM
To: Struts Developers List
Subject: Re: Where is Latest tiles-test-2.0-SNAPSHOT.war???

Yes, tiles2 will be based off of 1.5.  My guess would be that this
change was made about 4 weeks ago. . .when it's released, we'll provide
a retro-translator version.


David

Stone, Sam wrote:
 > Thanks. Did this change from jdk 1.4 to 1.5 in the last few weeks?
 >
 > Sam
 >
 >
 > -----Original Message-
 > From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H.
 > DeWolf
 > Sent: Tuesday, December 12, 2006 10:45 AM
 > To: Struts Developers List
 > Subject: Re: Where is Latest tiles-test-2.0-SNAPSHOT.war???
 >
 > The most recent 'stable' snapshot is:
 >
 > 2.0-r480013-SNAPSHOT
 >
 > and is in the snapshot repo:
 >
 > http://people.apache.org/repo/m2-snapshot-repository/
 >
 > If you need consistency, this one won't be changed underneath you.
 >
 >
 > David
 >
 >
 > Stone, Sam wrote:
 >> Where is latest downloadable tiles-test war file?
 >>
 >> -
 >> To unsubscribe, e-mail: [EMAIL PROTECTED]
 >> For additional commands, e-mail: [EMAIL PROTECTED]
 >>
 >>
 >
 > -
 > To unsubscribe, e-mail: [EMAIL PROTECTED]
 > For additional commands, e-mail: [EMAIL PROTECTED]
 >
 >
 > -
 > To unsubscribe, e-mail: [EMAIL PROTECTED]
 > For additional commands, e-mail: [EMAIL PROTECTED]
 >
 >

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: referencing spring beans from struts.xml

[David H. DeWolf]

Though, one thing I really like about the current implementation, which 
I think Ted alluded to, is the ability to not only support different 
implementations but allow them to be easily swapped.


If I have a service facade which is implemented by two swappable but 
different implementations, in the current scheme, one could be glued 
together with spring and the other with another IoC container without 
having to duplicate the action config.


David

David Durham wrote:

Ted Husted wrote:

On 12/12/06, Don Brown <[EMAIL PROTECTED]> wrote:


>   
>
> or something like that to kind of indicate to a developer, "Hey, this
> isn't a standard java class name."
>
Good point.  I like this idea more because it would allow us to use
multiple object factories simultaneously.  You know, you should make an
object factory that parses prefixes to delegate to the proper object
factory... :)


If all of my Actions are being injected, then a prefix adds no
information. It's just six more characters to type (and possibliy
mistype) in each and every attriibute. We'd just be saying "smurf
smurf smurf" :)


The added information is, perhaps, clarity, though you make a strong 
argument for possible dubiousness on that point.  My original thinking 
about this was "this took way to long to figure out, maybe this doc 
should have it as a bulleted item."  Then, I thought "wait, the action 
configiruation isn't explicit about this element."  Anyway, if clarity 
is not an issue, determinacy certainly is, because name-space collisions 
are possible.  Maybe solved by an order property like:

objectFactoryOrder = spring, new

Or does this already exist?


-Dave

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Where is Latest tiles-test-2.0-SNAPSHOT.war???

[David H. DeWolf]

Yes, tiles2 will be based off of 1.5.  My guess would be that this 
change was made about 4 weeks ago. . .when it's released, we'll provide 
a retro-translator version.



David

Stone, Sam wrote:
Thanks. Did this change from jdk 1.4 to 1.5 in the last few weeks? 


Sam


-Original Message-----
From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H.
DeWolf
Sent: Tuesday, December 12, 2006 10:45 AM
To: Struts Developers List
Subject: Re: Where is Latest tiles-test-2.0-SNAPSHOT.war???

The most recent 'stable' snapshot is:

2.0-r480013-SNAPSHOT

and is in the snapshot repo:

http://people.apache.org/repo/m2-snapshot-repository/

If you need consistency, this one won't be changed underneath you.


David


Stone, Sam wrote:

Where is latest downloadable tiles-test war file?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Where is Latest tiles-test-2.0-SNAPSHOT.war???

[David H. DeWolf]

The most recent 'stable' snapshot is:

2.0-r480013-SNAPSHOT

and is in the snapshot repo:

http://people.apache.org/repo/m2-snapshot-repository/

If you need consistency, this one won't be changed underneath you.


David


Stone, Sam wrote:

Where is latest downloadable tiles-test war file?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r484626 - in /struts/struts2/trunk: apps/showcase/src/main/java/org/apache/struts2/showcase/xslt/ apps/showcase/src/main/resources/ apps/showcase/src/main/webapp/xslt/ core/src/main/ja

[David H. DeWolf]

Ted Husted wrote:

Is this related tt http://issues.apache.org/struts/browse/WW-1550 ?



Yes, partially.  I still think that the matchingPattern and 
excludingPattern should be reintroduced as well, but this definately 
helps with the majority of situations for which they are needed.



It's just that we're trying to link all the commits to JIRA issues, to
simplify preparing the release notes.


No problem. . .Seems like we may want to get the Jira Subversion Plugin 
installed.




-Ted.

On 12/8/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Author: ddewolf
Date: Fri Dec  8 07:02:24 2006
New Revision: 484626

URL: http://svn.apache.org/viewvc?view=rev&rev=484626
Log:
Providing a mechanism which allows only portions of the action to be 
exposed/converted to XML by the XSLT result




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release the struts-master pom v4

[David H. DeWolf]

+1

Niall Pemberton wrote:

I'd like to release version 4 of the struts-master pom.

The repository has been tagged:
 http://svn.apache.org/viewvc/struts/maven/tags/STRUTS_MASTER_4/

Pom version 4 available for review here:
 http://people.apache.org/builds/struts/STRUTS_MASTER_4/

This is the master pom from which struts-parent inherits, and it needs
to be released for future Struts1 (and I assume 2) releases

Changes since v3 include:
- David DeWolf added
-  element id changed from "apache.snapshot" to
"struts-staging" and now points to
 people.apache.org/builds/struts/m2-staging-repository
-   element now points to
 people.apache.org/repo/m2-snapshot-repository

Here's my +1.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Tiles TLP

[David H. DeWolf]

Niall Pemberton wrote:

On 12/6/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:

I like it, sounds good!  Does that mean we're done until approval?

When is the next board meeting? Any one know?  How do we get this on
their agenda?


I asked Henri Yandell

The next board meeting is Wednesday 20th December and the resolution
would need to be in by Monday of that week (but the earlier the better
IMO, then you get time to iron out any wrinkles before the deadline).
He says you can email it to board@ but hes not sure whether it has to
be a member or if anyone can do it.


Ok, thanks for asking.  My guess is that it might look best coming from 
the new Chair too. Greg, I guess this is where I hand things off and 
tell you to let me know if you need help driving something to conclusion :)


I'll get back to coding!

David



Niall


Greg Reddin wrote:
>
> On Dec 6, 2006, at 12:20 PM, Nathan Bubna wrote:
>
>> to be constructively critical, perhaps it would help to say that i
>> think of it as a page composition and layout management framework.
>> perhaps that language would be useful?
>>
>> On 12/6/06, Nathan Bubna <[EMAIL PROTECTED]> wrote:
>>> hey now, Tiles works well without JSP too. :)
>
> I had a feeling that would come up :-)
>
> I just changed it to use your exact wording.
>
> Thanks,
> Greg
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Tiles TLP

[David H. DeWolf]

I like it, sounds good!  Does that mean we're done until approval?

When is the next board meeting? Any one know?  How do we get this on 
their agenda?


Greg Reddin wrote:


On Dec 6, 2006, at 12:20 PM, Nathan Bubna wrote:


to be constructively critical, perhaps it would help to say that i
think of it as a page composition and layout management framework.
perhaps that language would be useful?

On 12/6/06, Nathan Bubna <[EMAIL PROTECTED]> wrote:

hey now, Tiles works well without JSP too. :)


I had a feeling that would come up :-)

I just changed it to use your exact wording.

Thanks,
Greg




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r483061 - /struts/struts2/trunk/core/src/main/java/org/apache/struts2/config/PropertiesSettings.java

[David H. DeWolf]

Done.

Thanks

Antonio Petrelli wrote:

[EMAIL PROTECTED] ha scritto:

+try {
+in.close();
+} catch(IOException io) {
+LOG.warn("Unable to close input stream");
+}
  


Just a suggestion, put the exception in the LOG.warn instruction.

Ciao
Antonio

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Struts 2.0.2 Build - ON HOLD

[David H. DeWolf]

I'm assuming this is still the issue holding us up. . .if there's 
anything else that needs to be done prior to the release, I've got some 
spare cycles for the next few days to help push it.  Just let me know


David

Ted Husted wrote:

I just filed

* https://issues.apache.org/struts/browse/WW-1537

Links in the showcase that refer to namespaces are rendering the
webapp root twice.

* http://localhost:8080/struts2-showcase/struts2-showcase/tags/non-ui/
    
The problem breaks a lot of the showcase links, and is going to break
links in other applications that use namespaces or paths in URL links.

It might be something simple, but we should fix it before tagging a build.

For now, I'm going to look at other things in the Showcase, in the
hope someone has a quick solution to WW-1537.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s1+tiles2] Where does Tiles2-Struts1 integration belong?

[David H. DeWolf]

Greg Reddin wrote:
One alternative I thought of last night is to bring Struts-Tiles into 
the TLP as Tiles 1x.  We could quickly get a GA out so Tiles would have 
a GA in and of itself.  Then we could continue work on Tiles 2.


Does anyone else see the need for that?


I'd prefer not.  I think Tiles2 allows us to take a clean cut and 
dragging Tiles1 along forces us to include some major struts dependencies.


If compatibility is the major reason why you're looking for it, I'd much 
rather provide a compatibility package - much like what struts2 provides 
for struts1.


David




Thanks,
Greg

On Dec 5, 2006, at 9:38 AM, Antonio Petrelli wrote:


Niall Pemberton ha scritto:

Better IMO to be in Struts1 - but until Tiles2 has a "GA" release the
current "struts-tiles" module can't be replaced, otherwise it will
prevent a "GA" release of Struts1. If you're ready to start work on
this now then we could copy the exisiting code to a new
"struts-tiles2" module and remove the old module once tiles has gone
GA.


Agreed!


The other question in my mind is how much does tiles2 break
compatibility with the existing struts-tiles? If it does break
compatibility then perhaps we should just leave the existing
"struts-tiles" module to wither and decay rather than
removing/replacing.


Well, Tiles 2 breaks compatibility completely.
So I will create a new module.

Thank you
Antonio

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[RESULTS] Re: [VOTE] Tiles TLP

[David H. DeWolf]

Great news.  We have consensus regarding the fact that we should ask the 
board to approve the Tiles TLP Resolution.


+1 - 10
 0 - 0
-1 - 0

During voting a couple of things came up:

1) We should not submit the resolution with the original proposal. 
Instead, the resolution should suffice.


2) We may want to add a "small self-referential description" in order 
avoid the board requesting more info.


#1 is easily enough to take care of. . .how do we go about adding a 
tiles description to the legal jargon in the resolution?  Any examples?



David




David H. DeWolf wrote:
I'd like to begin the vote on the Tiles TLP Proposal [1] and Resolution 
[2].


[] +1  = Yes, let's ask the board to establish the Tiles TLP
[] +0  = I'm in favor, to some extent.
[] -0  = I'm not in favor but won't prevent it from happening.
[] -1  = I'd rather see Tiles stay here or go somewhere else.


[1] http://wiki.apache.org/struts/TilesTopLevel
[2] http://wiki.apache.org/struts/TilesTlpResolution



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[RESULTS] Re: [VOTE] Tiles PMC Chair

[David H. DeWolf]

7 Votes for Greg.  I believe that we have a unanimous decision. 
Congratulations Greg.


I will update the board resolution with your name.


David

David H. DeWolf wrote:
I'd like to propose a vote for the Tiles PMC Chair.  The individual with 
the simple majority will be recommended to the board when we submit the 
resolution (assuming it passes).


[] David H. DeWolf (ddewolf)
[] Greg Reddin (greddin)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tiles 2 - How to dispatch to tiles servlet????

[David H. DeWolf]

Moving to Struts Users list, please reply there.

Antonio Petrelli wrote:
First of all this is a typical question to be submitted in Struts Users 
mailing list.

Anyway, since Tiles 2 is under development, I will answer anyway.

Stone, Sam ha scritto:

I can instantiate the DefinitionsFactory. I can get a
ComponentDefinition OK. I cannot figure out how to forward the request
from MyServlet to dispatch to my tiles servlet. Any help is greatly
appreciated.
  
Err... you can't, since TilesServlet does not accept connections (it is 
used without a servlet-mapping).

Anyway you can forward to (or include) your definition.


   ComponentContext context = 
TilesAccess.getContainer(request.getSession().getServletContext())

   .render(request, response, "my.definition.name");



Just to avoid confusion, I don't think Antonio meant to imply that the 
Container.render returns a ComponentContext.


TilesContainer tc = TilesAccess.getContainer(servletContext)
ComponentContext context = tc.getComponentContext(req, res);
// do something with the component context if needed,
tc.render(req, res, "my.definition.name");


David



HTH
Antonio

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s1+tiles2] Where does Tiles2-Struts1 integration belong?

[David H. DeWolf]

If Tiles is to be truly standalone, it's my opinion that all of the 
integration should be in the component that is embedding tiles - not in 
tiles itself.  Otherwise, the Tiles PMC will end up having to track 
Struts1, Struts2, Velocity, Shale, and all sorts of other integration 
points.  I don't think that's a good idea.


So, I agree:

> 1. in Struts 1, replacing the current "struts-tiles" module;


Antonio Petrelli wrote:

Hello!
I am now facing the problem of the integration of Tiles 2 with Struts 1, 
there is a JIRA issue for this:

http://issues.apache.org/struts/browse/SB-15

I wish to know from you if this integration must be put:
1. in Struts 1, replacing the current "struts-tiles" module;
2. in Tiles, creating a new module.

I wish you to know that I am in favour of the first option, where 
integration code (that, correct me if I am wrong, is made of TilesAction 
and TilesPlugin) will be refactored to use Tiles 2 code, and all code 
moved to Tiles 2 will be removed.


What do you think?

Ciao
Antonio

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Tiles PMC Chair

[David H. DeWolf]

David H. DeWolf wrote:

[x] Greg Reddin (greddin)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Tiles TLP

[David H. DeWolf]

David H. DeWolf wrote:


[x] +1  = Yes, let's ask the board to establish the Tiles TLP


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Tiles PMC Chair

[David H. DeWolf]

I'd like to propose a vote for the Tiles PMC Chair.  The individual with 
the simple majority will be recommended to the board when we submit the 
resolution (assuming it passes).


[] David H. DeWolf (ddewolf)
[] Greg Reddin (greddin)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Tiles TLP

[David H. DeWolf]

I'd like to begin the vote on the Tiles TLP Proposal [1] and Resolution [2].

[] +1  = Yes, let's ask the board to establish the Tiles TLP
[] +0  = I'm in favor, to some extent.
[] -0  = I'm not in favor but won't prevent it from happening.
[] -1  = I'd rather see Tiles stay here or go somewhere else.


[1] http://wiki.apache.org/struts/TilesTopLevel
[2] http://wiki.apache.org/struts/TilesTlpResolution

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [tiles2] Tiles TLP and Dimensions incubation

[David H. DeWolf]

I'd like to wait until the TLP is established, just to make sure we 
don't muddy the Tiles water with confusion.  Let's get the TLP 
established and then move forward with this. . .that way we can get an 
alpha out sooner :)


D

Antonio Petrelli wrote:

Craig McClanahan ha scritto:

The Dimensions code is going to have to go through
the Incubator -- even though its likely that this can go very quickly, 
there
is no reason to mess up the progress of the Tiles TLP proposal by 
trying to

do them together.


Hi Craig, when I wrote "at the same time" I did not mean "together". 
Since probably Dimensions will become a subproject of Tiles TLP, I 
thought that probably it was appropriate to wait until it is estabilished.

I read this:

http://incubator.apache.org/incubation/Incubation_Policy.html#Sponsor


A Sponsor SHALL be either:
* the Board of the Apache Software Foundation;
* a Top Level Project (TLP) within the Apache Software Foundation (where 
the TLP considers the Candidate to be a suitable sub-project); or

* the Incubator PMC.


Antonio

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ajaxtags] autocompleter + question

[David H. DeWolf]

I'm getting the following when I start up the showcase in the trunk.  I 
took a look at the patch, and it doesn't seem to include the 
AutocompleterExampleAction.  Any ideas?


David


[ERROR] ] - Exception starting filter struts [org.apache.struts2.showcase.ajax.AutocompleterExampleAction] not found 
- action - 
file:/projects/open-source/struts2/apps/showcase/target/struts2-showcase/WEB-INF/classes/struts-ajax.xml:74:112>Action 
class [org.apache.struts2.showcase.ajax.AutocompleterExampleAction] not 
found - action - 
file:/projects/open-source/struts2/apps/showcase/target/struts2-showcase/WEB-INF/classes/struts-ajax.xml:74:112
	at 
com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.verifyAction(XmlConfigurationProvider.java:337)
	at 
com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.addAction(XmlConfigurationProvider.java:291)
	at 
com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.addPackage(XmlConfigurationProvider.java:378)
	at 
com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadPackages(XmlConfigurationProvider.java:242)
	at 
org.apache.struts2.config.StrutsXmlConfigurationProvider.loadPackages(StrutsXmlConfigurationProvider.java:111)
	at 
com.opensymphony.xwork2.config.impl.DefaultConfiguration.reload(DefaultConfiguration.java:146)
	at 
com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:52)


Musachy Barroso wrote:

Oh, I get it now. Is it Friday already ? :)

I have attached the patch for the autocompleter to WW-1529.

musachy

Martin Cooper wrote:

On 11/30/06, Musachy Barroso <[EMAIL PROTECTED]> wrote:


Where do you think we should put it? a tag?



No, no. That would be worse. The generic serialisation code should be in
some utility class somewhere, so that it can be used from wherever 
might be
appropriate. A result implementation would be the first place that it 
would

be used, but it may well be used in other places later (including
application code).

I have no idea. There are

also some comments that Don added that we should check out.



Yes. I haven't had the time to read through the whole JIRA thing yet,
though.

--
Martin Cooper


"I think this has promise. First, I'd like to see the incoming

parameters better integrated into the ActionContext. In particular, the
parameters should populate the parameters map in the ActionContext, and
OGNL should be used for the Action population rather than by custom 
means.


Also, it would be interesting to make the result selection happen
outside the Action somehow. For example, say you had an Action that
returned HTML. It would be interesting to somehow call that Action via
Ajax but get JSON back instead, without the Action having to return a
different result code. "

Rainer, I'm going to submit my patch for the autocompleter the way it is
now, and when we get this done, (if we do) then I will modify the
example, sounds good?

regards
musachy

Martin Cooper wrote:
> On 11/30/06, Musachy Barroso <[EMAIL PROTECTED]> wrote:
>>
>> Yeah, they are not tied to ajax at all, so they shouldn't have "ajax"
in
>> the name if that is what you mean, but are you against having a JSON
>> result type that will take care of the serialization for you?
>
>
> Yes, I was cringing at the naming with AJAX in there. No, I'm not
against
> having a JSON result type, but the serialisation code itself should
> not be
> buried in there, because people might want to use that for something
> else (
> e.g. embedding some JSON output within generated HTML).
>
> --
> Martin Cooper
>
>
> regards
>> musachy
>>
>> Martin Cooper wrote:
>> > On 11/30/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Musachy and others,
>> >> sounds like we should finally add an AJAXResult...
>> >> There have been efforts to create an AjaxJSON and AjaxXML result
type
>> >> already.
>> >
>> >
>> > Please, please decouple the notion of rendering / serialising to 
JSON

>> and
>> > XML from "AJAX". They are completely unrelated. Both JSON and 
XML are

>> > used
>> > much more widely than in just AJAX scenarios now.
>> >
>> > Also, note that there are lots of JSON serialisers out there. See
>> > http://json.org/ for a list. The json.org one is also public 
domain.

>> >
>> > --
>> > Martin Cooper
>> >
>> >
>> > So may be we should add this to the core of Struts2 now.
>> >> Have a look at http://issues.apache.org/struts/browse/WW-1330 for
>> more
>> >> details.
>> >>
>> >> What do you think?
>> >>
>> >> -Rainer
>> >>
>> >> > I was finishing the autocompleter examples tonight (annoying 
patch

>> >> coming
>> >> > soon:) ) and I have a couple of questions. The autocompleter 
when

>> used
>> >> in
>> >> > the "ajax" theme needs the action to return a JSON name/value
list,
>> >> should
>> >> > we provide any easy way to generate the response from the
>> action? In
>> >> > showcase I'm using a freemaker template as an example, but 
that's

>> >> going
>> >> to
>> >> > be a repetitive task for 

Re: [PROPOSAL] Tiles TLP

[David H. DeWolf]

Ted Husted wrote:

I'd suggest announcing the draft proposal to the Shale and MyFaces
lists, and inviting interested *committers* from those projects to
sign up on the wiki.



Done, thanks!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[OT] Tiles TLP Proposal

[David H. DeWolf]

[NOTE: This is a cross post to get your attention, Please only reply to 
the dev@struts.apache.org list]


I'd like to bring to this list's attention the proposal [1] and board 
resolution [2] for Tiles TLP that have been put together on the Struts 
wiki.  We'd like to invite any committers with previous exposure to 
Tiles to sign up on the wiki as interested.  Please also provide any 
necessary feedback and feel free to join our discussions on the struts 
developer list.


Thanks,

David

[1] http://wiki.apache.org/struts/TilesTopLevel
[2] http://wiki.apache.org/struts/TilesTlpResolution

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Tiles TLP

[David H. DeWolf]

David H. DeWolf wrote:


1) Flush out the initial Commiter PMC
   - who else is interested?
   - who else should we invite?



Ted, should I put you on the committer and pmc lists?

The proposal also lists David Geary, Matthias Wessendorf, and Cedric 
Dumoulin as possible candidates.  Should we


- automatically put them on the committer and pmc lists?
- send individual emails to invite them?
- leave them off the list unless they express interest?

I'm not sure what the protocol is here.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Tiles TLP

[David H. DeWolf]

Ted Husted wrote:


As for someone else, I would just like to point out that Wendy is a
Member, and she is also conversant with the ins and outs of
infrastructure. :)



Any interest Wendy?

Currently we have nominations (and willingness from those nominated) for:

- David
- Greg

Since it seems like most of the active participants have put in their 
2ce, I'll propose a vote on the chair once I hear back from you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Tiles TLP

[David H. DeWolf]

Antonio Petrelli wrote:

David H. DeWolf ha scritto:

2) Decide on a PMC Chair
   - who is interested?


As I can see from this question, then you probably you're not interested 
:-) Or are you?


I would prefer not. Reasons why:

1) Not an ASF Member

2) My Apache committer experience is either limited to either small 
projects with little community (Pluto) or a relatively short period of 
time (struts), and because of that, am not convinced I know the ins and 
outs of the foundation.  I think I'll learn a lot from being a part of 
the PMC first.


3) Don't really want to get caught up doing administrative things 
(though I'm willing to help write a board report here and there).


All of that said, if others would like me to or if no one else 
volunteers, I'm willing to do it. I'd just prefer to find someone else 
with a little more "apache grey hair" so to speak.


Greg, are you interested at all?


David




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PROPOSAL] Tiles TLP

[David H. DeWolf]

I'd like to bring to the list's attention the proposal [1] and board 
resolution [2] for Tiles TLP that have been put together on the Struts 
wiki.  Please provide any necessary feedback.


In addition to coming to consensus that these look good, I believe that 
we need to complete the following prior to voting:


1) Flush out the initial Commiter PMC
   - who else is interested?
   - who else should we invite?

2) Decide on a PMC Chair
   - who is interested?
   - who would others like to see?

3) What else?  I've never done this, so HELP!?!?
   - once voted, how do we bring this to the boards attention?
   - should we notify other projects that may be interested?
   - . . .?

Please send thoughts on these two topics.


David

[1] http://wiki.apache.org/struts/TilesTopLevel
[2] http://wiki.apache.org/struts/TilesTlpResolution

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Moving OverDrive to Apache Labs

[David H. DeWolf]

+1

Ted Husted wrote:

If no one minds, I'd like to apply to Apache Labs to host the
OverDrive code, now found in the Struts sandbox. It's greenfield
C#/ASP.NET stuff, and there's no direct connection to the Struts
codebase.

* http://labs.apache.org

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)

[David H. DeWolf]

Greg Reddin wrote:


On Nov 28, 2006, at 1:48 PM, David H. DeWolf wrote:


And, who's volunteering to Chair?


Perhaps it goes without saying, but the chair is actually appointed by 
the ASF board, we can only make a suggestion.


Though, it probably doesn't make sense to propose the TLP if we can't 
find anyone willing to accept the role.  Right?




I went digging for some information about the role of a chair and found 
these:


http://www.apache.org/foundation/how-it-works.html#pmc
http://www.apache.org/dev/pmc.html#chair
http://www.apache.org/foundation/faq.html#why-are-PMC-chairs-officers
http://www.apache.org/foundation/bylaws.html (Section 6.3)

What I'm not sure of is whether there are any prequalifications for 
being a chair, for example, does a chair already have to be an ASF 
member or a PMC member of an Apache project?  Or is it basically 
"whoever the board wants to appoint"?


Greg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)

[David H. DeWolf]

Greg Reddin wrote:


On Nov 28, 2006, at 1:48 PM, David H. DeWolf wrote:


Greg Reddin wrote:

On Nov 28, 2006, at 1:19 PM, David H. DeWolf wrote:
Ok, I'm convinced.  I'm on board with a Tiles TLP.  If someone 
doesn't beat me to it, I'll go ahead and write something up on the 
wiki.
I'm still thinking but close :-)  Would the current TLP proposal 
suffice?


Good.  We need one thinker in the group :)

My plan was to use it as a template.  I think there's some updating to 
do. Is it ok to update it directly or do we need it around for 
reference and history?


Yes, I guess my question was, since we're using it as reference, does it 
make sense to force people to parse through the history and quote which 
version they're referencing, or is it easier to just copy and paste...


I'll edit what's there and if someone doesn't like it, we can roll it back!



I think the wiki keeps track of changes so history is built in.

Greg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)

[David H. DeWolf]

Greg Reddin wrote:


On Nov 28, 2006, at 1:19 PM, David H. DeWolf wrote:

Ok, I'm convinced.  I'm on board with a Tiles TLP.  If someone doesn't 
beat me to it, I'll go ahead and write something up on the wiki.


I'm still thinking but close :-)  Would the current TLP proposal suffice?


Good.  We need one thinker in the group :)

My plan was to use it as a template.  I think there's some updating to 
do. Is it ok to update it directly or do we need it around for reference 
and history?




What about other people?  Are David Geary and Matthias Wessendorf 
listening?  They were on the original TLP and might be interested in 
joining the project.  Craig also indicated his interest.  Wendy?  You're 
on every other apache project, might as well join this one too :-)  And 
let's not forget Cedric, if he's interested.


Honestly, one of the things that helped changed my mind was that others 
started chiming in saying that they're interested. Hopefully they'll all 
join too. . .


And, who's volunteering to Chair?



Greg



David

Nathan Bubna wrote:

On 11/28/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:
...

Perhaps I'm looking at this too selfishly, but I'm thinking that if
nothing else the teams can help each other with the infrastructure and
burden of being a TLP.  For example:

- Moderating Mail Lists
- Board Reports
- Managing Jira
- Community Oversight
- etc. . .

and the burden of all of these grows with the size of the community.
true, it's not a linear curve, but i think the benefits of shared
interest in a codebase are superior to those of size.

It seems to me like those types of tasks can take a lot of development
time away from a small team. I've heard of PMC Chairs that are consumed
by all of this overhead and stop committing code.  I don't ever want to
get to that point and it seems possible considering the fact that there
are only 3 of us - 2 that currently commit code.

this is especially prone to happen when the scope of the PMC is too
big.  too much to oversee and keep track of.

That said, I do think there's much more potential for commit overlap
than you give credit. Simply having access to the repo of a sister
project might spawn some interest.  I know that I'd be apt to dive into
FileUpload or WebParts if I had commit access.  I've used both before
but haven't contributed because the burden was too much for the 
benefit.

it might, but i'd advise against counting on cvs access alone to spur
involvment.

At the same time, while I'm sure Dimensions or Scopes are great, I just
don't have the need for them right now.  And because of that, I'd be
less apt to contribute.

true, but those interested in dimensions or scopes (i'm assuming
they're Tiles-dependent here) are much more apt to contribute to
Tiles.  and those who already know Tiles should be much more capable
of jumping in on dimensions or scopes (being closely related projects)
than they are on FileUpload.  consider email: it should be easier and
quicker for a Tiles committer to follow email about a closely
related/dependent project than it is to follow emails about unrelated
ones like FileUpload.  lack of focus will cost all the developers
time, not just the PMC chair.

In other words, I don't think it's "dependency" that makes people
contribute, I think it's weighing the benefit against the burden.  
If we

lower the burden for key people, they may come to play.

in both cases (Dimensions/Scopes vs FileUpload/WebParts) you are
talking about lowering the burden equally from an infrastructure point
of view, so that's a moot point.  and the conceptual burden of
contributing to a dependent project (Dimensions/Scopes) is already
lower than that of an unrelated project (FileUpload).
so, it's only the benefit side that is really in question here.  as to
that, investment in a project dependent on Tiles leads to investment
in Tiles much more often than investment in FileUpload would.  yes, in
the other direction (starting with investment in Tiles, like you, and
looking at Dimensions/Scopes), the benefit is highly personal and thus
essentially arbitrary, but it still seems more likely (due to the
lower conceptual burden).
take the umbrella metaphor itself:  umbrellas are much easier than
tarpaulins to manage because they have a specific, central pole to
which all the rest is firmly connected.  likewise, putting Tiles,
FileUpload, etc together in one project may have some benefits but is
going to be hard to manage effectively and move forward together
(Jakarta Commons and Jakarta itself are examples of this).




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-m

Re: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)

[David H. DeWolf]

Ok, I'm convinced.  I'm on board with a Tiles TLP.  If someone doesn't 
beat me to it, I'll go ahead and write something up on the wiki.


David

Nathan Bubna wrote:

On 11/28/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:
...

Perhaps I'm looking at this too selfishly, but I'm thinking that if
nothing else the teams can help each other with the infrastructure and
burden of being a TLP.  For example:

- Moderating Mail Lists
- Board Reports
- Managing Jira
- Community Oversight
- etc. . .


and the burden of all of these grows with the size of the community.
true, it's not a linear curve, but i think the benefits of shared
interest in a codebase are superior to those of size.


It seems to me like those types of tasks can take a lot of development
time away from a small team. I've heard of PMC Chairs that are consumed
by all of this overhead and stop committing code.  I don't ever want to
get to that point and it seems possible considering the fact that there
are only 3 of us - 2 that currently commit code.


this is especially prone to happen when the scope of the PMC is too
big.  too much to oversee and keep track of.


That said, I do think there's much more potential for commit overlap
than you give credit. Simply having access to the repo of a sister
project might spawn some interest.  I know that I'd be apt to dive into
FileUpload or WebParts if I had commit access.  I've used both before
but haven't contributed because the burden was too much for the benefit.


it might, but i'd advise against counting on cvs access alone to spur
involvment.


At the same time, while I'm sure Dimensions or Scopes are great, I just
don't have the need for them right now.  And because of that, I'd be
less apt to contribute.


true, but those interested in dimensions or scopes (i'm assuming
they're Tiles-dependent here) are much more apt to contribute to
Tiles.  and those who already know Tiles should be much more capable
of jumping in on dimensions or scopes (being closely related projects)
than they are on FileUpload.  consider email: it should be easier and
quicker for a Tiles committer to follow email about a closely
related/dependent project than it is to follow emails about unrelated
ones like FileUpload.  lack of focus will cost all the developers
time, not just the PMC chair.


In other words, I don't think it's "dependency" that makes people
contribute, I think it's weighing the benefit against the burden.  If we
lower the burden for key people, they may come to play.


in both cases (Dimensions/Scopes vs FileUpload/WebParts) you are
talking about lowering the burden equally from an infrastructure point
of view, so that's a moot point.  and the conceptual burden of
contributing to a dependent project (Dimensions/Scopes) is already
lower than that of an unrelated project (FileUpload).

so, it's only the benefit side that is really in question here.  as to
that, investment in a project dependent on Tiles leads to investment
in Tiles much more often than investment in FileUpload would.  yes, in
the other direction (starting with investment in Tiles, like you, and
looking at Dimensions/Scopes), the benefit is highly personal and thus
essentially arbitrary, but it still seems more likely (due to the
lower conceptual burden).

take the umbrella metaphor itself:  umbrellas are much easier than
tarpaulins to manage because they have a specific, central pole to
which all the rest is firmly connected.  likewise, putting Tiles,
FileUpload, etc together in one project may have some benefits but is
going to be hard to manage effectively and move forward together
(Jakarta Commons and Jakarta itself are examples of this).





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Updated Tiles Graduation Proposal

[David H. DeWolf]

Craig McClanahan wrote:



Writing code is much more fun than writing umbrella project charter
documents :-).


+1000



Craig




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)

[David H. DeWolf]

Greg Reddin wrote:

2)  Apache Web Components TLP - What components will make up this 
list?  Who needs to be involved in the discussion?  What's the 
process to proceed?


This is my preference.  I think the next steps would be to follow up 
with the other potential projects to see if they are even interested. 
The core ones that I'd start talking to are:


- Tiles (Apache)
- Jakarta Commons File Upload (Apache)
- Java Web Parts (SF)
- XAP (Apache Incubator)


I see this as being difficult to get approved, much less operational.  I 
think we need to have a real convincing argument for all these things to 
live together before we head down this road - not just for political 
reasons but practical reasons also. I'm not sure how this helps our 
community situation.  Why would a Web Parts developer start contributing 
to Tiles just because they are part of the same TLP.  I'm a Struts 
committer, but I've contributed very little to anything outside of 
Tiles.  I'm also a Shale committer, but I've not contributed much to the 
other parts of that project yet either.  Community doesn't just happen 
because we live in the same neighborhood or even the same house.  There 
has to be a common goal that will cause people to want to work on Tiles 
specifically I think.   It would make sense to bring Dimensions and 
Scopes into a Tiles project.  They deal directly with Tiles.  People 
interested in one will be interested in the other.  But the above list 
of components just don't have enough in common to build that kind of 
community IMO.




Perhaps I'm looking at this too selfishly, but I'm thinking that if 
nothing else the teams can help each other with the infrastructure and 
burden of being a TLP.  For example:


- Moderating Mail Lists
- Board Reports
- Managing Jira
- Community Oversight
- etc. . .

It seems to me like those types of tasks can take a lot of development 
time away from a small team. I've heard of PMC Chairs that are consumed 
by all of this overhead and stop committing code.  I don't ever want to 
get to that point and it seems possible considering the fact that there 
are only 3 of us - 2 that currently commit code.


That said, I do think there's much more potential for commit overlap 
than you give credit. Simply having access to the repo of a sister 
project might spawn some interest.  I know that I'd be apt to dive into 
FileUpload or WebParts if I had commit access.  I've used both before 
but haven't contributed because the burden was too much for the benefit.


At the same time, while I'm sure Dimensions or Scopes are great, I just 
don't have the need for them right now.  And because of that, I'd be 
less apt to contribute.


In other words, I don't think it's "dependency" that makes people 
contribute, I think it's weighing the benefit against the burden.  If we 
lower the burden for key people, they may come to play.





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)

[David H. DeWolf]

Greg Reddin wrote:


On Nov 28, 2006, at 9:46 AM, David H. DeWolf wrote:

3) Apache Tiles TLP - Seems we could do this here and now and submit 
a proposal to the board.  Who else should we bring into the discussion?


Doable, and probably the easiest to get going - but also the hardest 
to maintain.  It doesn't seem to me like there are enough interested 
parties to carry the load.


Ok, so here's the really hard question - do we have a community?  The 
number of people contributing to Tiles has grown from one to three (and 
I haven't really contributed anything but ideas in a while).  I don't 
mean in any way to diminish the contributions of those who built Tiles 
in the first place or initially moved it to the sandbox.  But where does 
it go in the future?  I don't want to spend a whole lot of time lobbying 
for and building a TLP for three people.  I suppose we could get it 
going to test the waters - if you build it they will come.  But I'm not 
sure if they will come yet.  There's a lot of people who *use* Tiles, 
but how many of them are legacy users who don't want to grow with it?  
How many of them will be contributors?



I have the same questions. That's exactly why I don't think a Tiles TLP 
is feasible at this point.  Having a WC TLP will allow us to include 
others and build more community. . .




I'd love to hear thoughts from people who have gone down this road with 
other projects as well as from David and Antonio.


Greg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Updated Tiles Graduation Proposal

[David H. DeWolf]

Antonio Petrelli wrote:

David H. DeWolf ha scritto:

Perhaps scope could be:

- Java
- Dependent on Serlvet/JSP
- Small Utilities that are/can be used Standalone or Embeded within 
frameworks


In this case XAP will be excluded since is a client (on browser) project.


agreed.  but such is life.  the more I read the archives, the more I 
think we need a tight ship.  If we go with this approach I think I'll 
even suggest in the charter that we release all components of WC 
together as one release (much like struts2 is released together along 
with it's plugins).





I think that (eventually) an Apache Web Components project should be 
topic-centered (the web) and cross-platform (not only Java EE, but also 
JavaScript, AJAX, and the "evil" .NET :-) ).


Perhaps, but I'm not yet convinced. . .I could see us extending the 
charter to allow ajax components.  Perhaps we should say dependent on 
Servlet/JSP or JavaScript.  I just think we'll have a harder time 
getting approval if we look like a "catch-all".  It will also be much 
harder to manage.


David




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Updated Tiles Graduation Proposal

[David H. DeWolf]

One thing I've noticed in the JWC threads that I've read is that all of 
the discussions take place in context of creating it as a "grouping" or 
"subproject" of Jakarta.  Since one of the main fears seems to be 
pushing releases too far away from the PMC, I wonder how a top level JWC 
with a formal (written) scope would change the discussion.


Perhaps scope could be:

- Java
- Dependent on Serlvet/JSP
- Small Utilities that are/can be used Standalone or Embeded within 
frameworks


David

Nathan Bubna wrote:

Sorry, should have put that in...

i would suggest either

A) Tiles as its own TLP:  Apache Tiles
B) Tiles as a Jakarta subproject:  Jakarta Tiles

if you do A, then keep your focus to Tiles.  that doesn't mean you
can't have other projects in a Tiles TLP; it just means they should be
either built specifically for use with Tiles or else dependent on
Tiles.

if you do B, then Tiles should never have any subprojects of its own,
but it can gather into a "grouping" or "sub-community" with other
Jakarta subprojects.  This is essentially what was proposed and
discussed in the thread i sent.

On 11/28/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:



Nathan Bubna wrote:
> I know i'm not really much involved with Tiles lately, but i'd just
> like to say that i think the idea of a topic-centered umbrella project
> is a bad idea and not especially likely to be favored by the ASF these
> days.

Just curious, what do you suggest instead?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Updated Tiles Graduation Proposal

[David H. DeWolf]

Nathan Bubna wrote:

I know i'm not really much involved with Tiles lately, but i'd just
like to say that i think the idea of a topic-centered umbrella project
is a bad idea and not especially likely to be favored by the ASF these
days.


Just curious, what do you suggest instead?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)

[David H. DeWolf]

Antonio Petrelli wrote:

David H. DeWolf ha scritto:


2)  Apache Web Components TLP - What components will make up this 
list?  Who needs to be involved in the discussion?  What's the 
process to proceed?


This is my preference.  I think the next steps would be to follow up 
with the other potential projects to see if they are even interested. 
The core ones that I'd start talking to are:


- Tiles (Apache)
- Jakarta Commons File Upload (Apache)
- Java Web Parts (SF)
- XAP (Apache Incubator)


Oops, forgot:

- Jakarta Taglibs (Apache)



+1

By the way, I already subscribed to XAP mailing list, I am going to ask 
them about it.


Antonio


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)

[David H. DeWolf]

Greg Reddin wrote:


Since we've failed to build consensus, I've published a versioned 
snapshot that will have to suffice for 2.0.2 and I will begin to drive 
the effort for TLP :( - it's not my preference but it will have to work.


Hang on, slow down just a bit :-)  Before we jump off the TLP cliff 
let's make sure we know all the options and have consensus from 
everybody involved.


Ok!



Here's the viable choices as I see them:

1)  Jakarta Web Components Subproject - What components will make up 
this list?  Who all needs to be involved in the discussion?


I'm not inclined to follow this path as Jakarta is already quite a 
diverse group that is trying to become more centralized/focused in order 
to build more community.  Brining in a new developers with no other 
involvement in that community into the mix seems to create more 
disconnect - not more community.


2)  Apache Web Components TLP - What components will make up this list?  
Who needs to be involved in the discussion?  What's the process to proceed?


This is my preference.  I think the next steps would be to follow up 
with the other potential projects to see if they are even interested. 
The core ones that I'd start talking to are:


- Tiles (Apache)
- Jakarta Commons File Upload (Apache)
- Java Web Parts (SF)
- XAP (Apache Incubator)

3) Apache Tiles TLP - Seems we could do this here and now and submit a 
proposal to the board.  Who else should we bring into the discussion?


Doable, and probably the easiest to get going - but also the hardest to 
maintain.  It doesn't seem to me like there are enough interested 
parties to carry the load.


The original proposal that Ted referenced included the following three 
individuals:  David Geary, Nathan Bubna, Matthias Wessendorf. I wonder 
if they are still interested.




Options that have been discussed and rejected:

1)  Struts subproject - Struts does not need to become an umbrella.
2)  Jakarta Commons component - Tiles is more of a framework than most 
of the components under commons.  Several people have voiced their 
objection to this approach.

3)  Struts2 Tiles Plugin - Removes the "standalone" nature of Tiles.

So... of the three viable options, let's discuss and decide where to go 
from here.


I'm willing to run with #2 and try to drive it.  I'll gladly participate 
and help someone else with either of the other options.


David


Greg




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Struts 2.0.2 Build

[David H. DeWolf]

David H. DeWolf wrote:


I'm assuming the first command should be

mvn install site -P all,pre-assembly



The following:

$> mvn install site -P all,pre-assembly
$> cd assembly/
$> mvn assembly:assembly

works for me and produces:

lion:/projects/open-source/struts2/assembly/target ddewolf$ ls -al 
assembly/out

total 177280
drwxr-xr-x   6 ddewolf  admin   204 Nov 28 10:12 .
drwxr-xr-x   3 ddewolf  admin   102 Nov 28 10:11 ..
-rw-r--r--   1 ddewolf  admin  40777286 Nov 28 10:12 
struts-2.0.2-SNAPSHOT-all.zip
-rw-r--r--   1 ddewolf  admin  23173784 Nov 28 10:12 
struts-2.0.2-SNAPSHOT-apps.zip
-rw-r--r--   1 ddewolf  admin   6534839 Nov 28 10:12 
struts-2.0.2-SNAPSHOT-lib.zip
-rw-r--r--   1 ddewolf  admin  20271915 Nov 28 10:12 
struts-2.0.2-SNAPSHOT-src.zip


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Struts 2.0.2 Build

[David H. DeWolf]

It fails for me:

[INFO] snapshot org.apache.struts:struts2-struts1-plugin:2.0.2-SNAPSHOT: 
checking for updates from opensymphony

[INFO] [assembly:assembly]
[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] Error creating assembly

Embedded error: /projects/open-source/struts2/assembly/../target/site 
isn't a directory.
[INFO] 


[INFO] For more information, run Maven with the -e switch
[INFO] 


[INFO] Total time: 18 seconds
[INFO] Finished at: Tue Nov 28 10:02:03 EST 2006
[INFO] Final Memory: 8M/14M
[INFO] 




I'm assuming the first command should be

mvn install site -P all,pre-assembly

What is the pre-assembly profile? I can't find it in the parent pom or 
in the assembly pom?



David

Ted Husted wrote:

Hmmm, if we might have a memory link during tests, then I'd want to be
sure that we don't have a leak during production as well. I'll setup
an integration test suite that we can run against the showcase
and/mailreader in a loop, and try to let it run overnight.

In the meantime, could someone else try running

$ mvn install -P all,pre-assembly
$ cd assembly
$ mvn assembly:assembly

so we confirm that it's a systemic build error, and not an issue with my 
system.


-Ted.


On 11/28/06, Don Brown <[EMAIL PROTECTED]> wrote:

Ted Husted wrote:

> Another bit of strangeness is that I can't get a clean build from my
> usual checkout. It fails on the ActionTag tests. If I try from another
> struts2 checkout (not adjacent to my XWork working copy), it builds
> fine, up to the last mile.

I noticed that once or twice, I got an out of memory exception while
running the tests.  Somewhere in all the Dispatcher and configuration
refactoring, we might have overlooked somewhere that is leaking memory
on the tests.  This only happened to me when I tried to enable the xwork
and plugin profiles.  When building core directly, it didn't have any
problems.  I had this exception problem during the initial configuration
redesign of xwork2, but some cleanup in tearDown() and new objects in
setUp() fixed it.

Don

> -Ted.
>
> [INFO]
> 


> [ERROR] BUILD ERROR
> [INFO]
> 


> [INFO] Failed to resolve artifact.
>
> GroupId: opensymphony
> ArtifactId: xwork
> Version: 2.0-beta2
>
> Reason: Unable to download the artifact from any repository
>
> Try downloading the file manually from the project website.
>
> Then, install it using the command:
>mvn install:install-file -DgroupId=opensymphony -DartifactId=xwork \
>-Dversion=2.0-beta2 -Dpackaging=jar -Dfile=/path/to/file
>
>
>  opensymphony:xwork:jar:2.0-beta2
>
> from the specified remote repositories:
>  Maven Snapshots (http://snapshots.maven.codehaus.org/maven2/),
>  central (http://repo1.maven.org/maven2),
>  opensymphony (http://maven.opensymphony.com),
>  apache.snapshots 
(http://people.apache.org/repo/m2-snapshot-repository),

>  snapshots-maven-codehaus (http://snapshots.maven.codehaus.org/maven2)
>
>
> [INFO]
> 


> [INFO] For more information, run Maven with the -e switch
> [INFO]
> 


> [INFO] Total time: 3 seconds
> [INFO] Finished at: Mon Nov 27 22:24:45 EST 2006
> [INFO] Final Memory: 4M/7M
> [INFO]
> 


>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Updated Tiles Graduation Proposal

[David H. DeWolf]

Ted Husted wrote:

On 11/28/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:

Do we really have that rule, or can Tiles do an alpha release out of
the Struts sandbox?


The Jakarta Commons has that rule, but it's never really come up
before. The new Apache Labs has a "no releases" rule too.

The Struts Charter does say that the subprojects are the unit of
release, and so to have a release, under the charter, we would need a
subproject.

But, a test-build is not a release, and, if it were helpful, Tiles
could have a tagged test build.



I'm +0 on Tiles 'graduating' from the sandbox to a Struts sub project.
 I think we'll spend a lot of time explaining that it's not *really*
tied to Struts anymore, despite living here and having a Maven groupId
of org.apache.struts.tiles.


At this point, I'm -1 on a Tiles subproject. It was always the
intention for Tiles to apply to TLP when the time came, and the time
has come.


Since we've failed to build consensus, I've published a versioned 
snapshot that will have to suffice for 2.0.2 and I will begin to drive 
the effort for TLP :( - it's not my preference but it will have to work.


Anyone interested in PMC Chair for Commons-Web Components?  Does it have 
to be an ASF Member or will any committer suffice?




-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Updated Tiles Graduation Proposal

[David H. DeWolf]

Ted Husted wrote:

On 11/28/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:

Yes, that was my point, that the incubator will resolve any community
issues.

I'll start to throw together a wiki proposal.


Incubator projects can also have releases.


But tiles (or any other current apache project for that matter) wouldn't 
have to go through the incubator - right?




-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[s2] Freemarker Showcase Failing

[David H. DeWolf]

Heads up. . .the freemarker showcase is currently failing.  I'm not sure 
when the bug was introduced.  If we can hold off on the 2.0.2 release, I 
can look into it this evening and either fix it or send an update. . .



David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Updated Tiles Graduation Proposal

[David H. DeWolf]

Antonio Petrelli wrote:

David H. DeWolf ha scritto:



Antonio Petrelli wrote:

David H. DeWolf ha scritto:





What other apache subprojects would fit under that TLP?


Jakarta Taglibs probably, and I have some doubt about Turbine.

I agree about Taglibs, I'll ask on the jakarta list.  I also agree on 
Turbine: I think we should keep these "web components" small - like a 
commons projects.  I'd hesitate to bring on a full webapp framework 
(like wicket, or turbine). Agree?


Yes, that's exactly what I had in mind.


How about Jakara Commons FileUpload?


Sure! I forgot it!


Should we consider these incubator projects:
- Abdera?
- XAP?
- Any others that I didn't notice?


XAP is interesting, but Abdera... I think it stays better on its own, or 
it could go to xml.apache.org


Makes sense,

Honestly, I know nothing about either of them.  I just scanned the 
incubator pages :)





As I previously wrote:
* Java Web Parts (probably it must be incubated): 



Definately.  Want to ask on their list?


Err sorry, do you want me to ask on their list or are you going to ask? 
Sorry, I did not understand you :-(

If it is the latter, yes :-)


Ok, I'll go ahead.  Didn't want to steal your thunder, so I was asking 
you if you wanted to. . .but that's ok, I'll take it.




* Scopes (donation by me, I am the only copyright owner and 
committer): http://scopes.sourceforge.net/

* Dimensions (needs incubation): http://mutidimensions.sourceforge.net/

http://javawebparts.sourceforge.net/

My only question about scopes and dimensions would be community. 
Incubation will help flush that out.


Scopes could be put as a sandbox project (we discussed on it about one 
month ago); Dimensions didn't reach a community at all, but isn't 
building a community a requirement to exit the incubator?



Yes, that was my point, that the incubator will resolve any community 
issues.


I'll start to throw together a wiki proposal.

David



Thanks for the feedback

Antonio

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]