David Gagnon ha scritto:
If the instance variable is at least protected and not final. It
would be possible to create my new WindowScopeEnabledTagUtils class
that inherit from tagUtils and change the instance for my new
instance. That would have been great! Is that can be done ? Is there
Hi Antonio,
I suppose that you want to use some window-scoped attribute in your
JSP page, right?
In this case I think that you could copy you attribute from window
scope to page scope (probably with some custom tag library) and then
use it, without changing Struts codebase.
HTH
Antonio
Yes
David Gagnon ha scritto:
Hi Antonio,
I suppose that you want to use some window-scoped attribute in your
JSP page, right?
In this case I think that you could copy you attribute from window
scope to page scope (probably with some custom tag library) and then
use it, without changing Struts
On 6/12/06, Craig McClanahan [EMAIL PROTECTED] wrote:
Having two frameworks to keep track of instead of one, each with their own
idiosyncracies and release trains, is not making life better for the
engineers that have to maintain that kind of a beast.
Well, it would have made Atlassian's life
I did an webBase ERP and in this context the window scope make sense.
One session, 3 windows, 1 Request and 1 page scope. And I do want to
change the implementation because this way I can use all the Struts
taglib without a change!
You are correct, but what if you are going to use JSTL
At 1:57 PM +0200 6/13/06, Antonio Petrelli wrote:
Yes that would be a workaround indeed but somewhat cumbersome since
I use this scope everywhere. I do think struts should offer a way
to change TagUtils behavior.
With the : private final TagUtils instance; there is clearly no
way in :-( It
Well, it would have made Atlassian's life easier.
JIRA is written with
WW1 and Confluence is written with WW2, the two
versions cannot
coexist in the same web application, and they still
haven't gotten
around to migrating JIRA. When people (like me) run
both applications,
we need to run
From: Craig McClanahan [EMAIL PROTECTED]
On 6/12/06, Wendy Smoak wrote:
On 6/12/06, Craig McClanahan wrote:
On 6/12/06, Gary VanMatre wrote:
I had to wack my m2 shale repos and then rebuild all of the
libraries. That was the was the ticket. I'm having trouble building
On 6/13/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Just so I'm clear, because I frankly wasn't paying attention previously
:)... are we favoring this Confluence instance over the Struts Wiki for
this sort of thing?
As it stands, all of the SAF2 documentation is under Confluence.
-Ted.
On 6/13/06, Gary VanMatre [EMAIL PROTECTED] wrote:
I tried a fresh checkout on
(https://svn.apache.org/repos/asf/struts/shale/branches/mvn_reorg). I'm still seeing the
same error when executing mvn clean install from the branch root or from
mvn_reorg/shale-test. Not sure what I've messed
Is it possible to have multiple chain configurations for the same Struts
1.3 app. For example, can you configure one module to use tiles and
another to not do so?
Regards,
Phil Zoio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Isn't possible to be an issue with XWork dependency? I don't think 2
different versions of XWork can co-exist on the same webapp but I
may be wrong.
./alex
--
.w( the_mindstorm )p.
On 6/13/06, Jason Carreira [EMAIL PROTECTED] wrote:
Well, it would have made Atlassian's life easier.
JIRA
From: Wendy Smoak [EMAIL PROTECTED]
On 6/13/06, Gary VanMatre wrote:
I tried a fresh checkout on
(https://svn.apache.org/repos/asf/struts/shale/branches/mvn_reorg). I'm still
seeing the same error when executing mvn clean install from the branch root
or
from mvn_reorg/shale-test.
At 9:23 PM +0100 6/13/06, Phil Zoio wrote:
Is it possible to have multiple chain configurations for the same
Struts 1.3 app. For example, can you configure one module to use
tiles and another to not do so?
It is technically possible to change which command is looked up in
the catalogs and
Ticket SB-21 [1] seeks to simplify the Tiles taglib API. First, it's
a given that this will break backwards compatibility. You can't
reduce an API without breaking compatibility. But as long as we're
seeing this version of Tiles as a rework, I don't think it's a
problem. Also, I don't
What about doing what Sun does with Xalan for Java 5 and rename XWork
packages? With the changes we are making to XWork 2.0, I don't think
it will co-exist with WebWork 2.2.2/3 very well, if at all.
Therefore:
com.opensymphony.xwork
will become:
Hi Ted... I wouldn't say there's no one interested in fixing the errors
:) I offered to do it some time ago, and I'm still willing (and my time
has freed up again, so able as well!)
I just started going through them... my plan was to do one package in
Core and see if anyone was willing to
On 6/13/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Hi Ted... I wouldn't say there's no one interested in fixing the errors
:) I offered to do it some time ago, and I'm still willing (and my time
has freed up again, so able as well!)
Unforutnately, it seems to be a timing issue. If the
Ok, that's no problem. Waiting might be better, especially since it
looks like at least some of it involves rule tweaking, and hence I'd
think some discussion. I don't want to do anything that makes getting
to GA more difficult, so I'm ok with coming back to it later.
Frank
Ted Husted
On 6/13/06, Gary VanMatre [EMAIL PROTECTED] wrote:
I removed the servlet API from the repo. The install downloads the 2.4 plugin
but it's not using it in the compile.
Can you send me (off-list) the output of mvn install -X for shale-test?
cd shale-test
mvn clean
mvn install -X build.log
If XWork were at Apache, it's hard to see it as anything but
'org.apache.xwork'. Is that not possible?
I think XWork truly deserves to stand on it's own (like it does
today) and not be tied to anything else. Surely it can live as a TLP
at Apache can it not?
--
James Mitchell
On
Theoretically, I agree with you. However, pushing a project through
Incubation takes a lot of work, and we are already stretched trying to
get a stable Action 2 release out. In order to meet our August target,
we have to get the feature scope wrapped up in the next few weeks, and
start
On 6/13/06, Ted Husted [EMAIL PROTECTED] wrote:
Right now, Wendy has been publishing 1.3.5 snapshots, and she may be
ready for another try at a release. I don't know if we want to get
into this again now or after we have a GA 1.3.
The 1.3 distribution is in good shape, I think, (but I've
I see, so short term, you want to repackage XWork with all the latest
changes under a new package name, but leave it at OS.
And looking long term, XWork ('org.apache.xwork') as an official
subproject under Apache Struts ;) ??? I'd vote +1
--
James Mitchell
On Jun 14, 2006, at 12:42
How about com.opensymphony.xwork2? :)
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=34229messageID=66656#66656
-
To unsubscribe,
I'd be fine with that too.
Don
Patrick Lightbody wrote:
How about com.opensymphony.xwork2? :)
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=34229messageID=66656#66656
26 matches
Mail list logo
