Struts Action 1.3.5-SNAPSHOT has been deployed to Apache's Maven 2
snapshot repo,
and the distributions are available here:
http://people.apache.org/builds/struts/maven/trunk/nightly/struts-action/
For more information, please see the release plan:
http://wiki.apache.org/struts/StrutsActionR
Hi Ian,
I think using DWR as the core library will come up with some
problems. For example
How do you get the return value for the javascript function you call?
(if receiveMessages() returns something )
How do you switch between polling and Comet?
Solution (From forum)
Right now y
Friends,
Pls Help, URGENT
I am gettting the following error when I invoke my Action class.
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () th
On Tue, May 23, 2006 2:57 pm, Ian Roughley wrote:
> What we came up with is:
> 1. Struts2 should be able to work generically as a data source for any
> ajax client. This would entail being able to return HTML and XML
> results, but also JSON results. Additionally, as well as populating the
> acti
The Mailbox rah is currently unavailable.
It is in deactivated state and is not receiving mails.
Your message reads:
Received: from gunner.electric.net (unverified [216.129.90.16]) (using TLSv1
with Cipher RC4(128), Exch RSA_SIGN(1024), Hash MD5(128)) by
securemail.onebox.com
(Rockliffe SMTPR
Hi everyone,
Wanted to document the discussion we had at JavaOne regarding ajax
support for Struts2. In attendance were Pat, myself and Martin from the
committers group, as well as Joe (from DWR) and a couple of other people
(my apologies for not writing down names).
The discussion focused
> Yep, we should branch XWork before you commit your
> changes. Shall I
> create a branch of the current CVS as XWORK_1_2?
> So you could commit your changes later into HEAD and
> Patrick could
> start the migration to SVN after this commit.
>
> Rainer
+1 (if we're voting)
---
Staying on CVS is probably a smarter descision for now but...
You could convert the repo to SVN, create a 1.xx branch and then you
could import your local copy into the trunk.
Never tried it but in theory it would work.
Cheers,
Eric
On 5/23/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
>
>
If Jason has a lot of uncommitted changes, it would
probably make
sense to let him commit them before migrating, if the
migration is to
go ahead.
Exactly, point #2.
But the problem is... If we're going to branch the old stuff, do I
want to check in my XWork 2.0 changes and then port to SVN, t
>
> It also may be wasted work if there's an idea that
> the whole
> repository may be moving again (that is, to Apache)
> in 6 months.
Exactly, point #1.
>
> That said, I recall people generally saying that the
> SVN
> import-from-CVS tools work pretty well, and they also
> are able to
> pr
FWIW, it wasn't done for WebWork mainly because it would have required getting
the infrastructure folks involved and from my conversations with folks, it
didn't seem like that big of deal. In retrospect, I would have done it
differently knowing now that, no matter how hard you try, Incubator ta
I've imported a CVS repo into SVN and the history was preserved. Worked
like a charm.
/Ian
--
From Down & Around, Inc.
Innovative IT Solutions
Software Architecture * Design * Development
~
web: www.fdar.com
email [EMAIL PROTECTED]
pho
At 12:20 PM -0500 5/23/06, Eric Molitor wrote:
My experience is that it's quite a bit faster than CVS (especially
over a WAN) but to be honest the biggest advantages I've seen are with
file moves, renames, and branching. SVN seems to handle them all
relatively painlessly which is a significant im
> My experience is that it's quite a bit faster than CVS (especially
> over a WAN) but to be honest the biggest advantages I've seen are with
> file moves, renames, and branching. SVN seems to handle them all
> relatively painlessly which is a significant improvement over CVS.
That's my experience
My experience is that it's quite a bit faster than CVS (especially
over a WAN) but to be honest the biggest advantages I've seen are with
file moves, renames, and branching. SVN seems to handle them all
relatively painlessly which is a significant improvement over CVS.
Also the SVN support in Int
Why move it to SVN? What does it gain? Just wondering how I'm going to
reconcile all these changes I've got that will be harder to do if we switch
repositories...
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jsp
Can you also take care about the CVS history?
It would be very good to still have the history available for further
development.
Rainer
> Sounds good to me. I can start the process of migrating to SVN.
> -
> Posted via Jive Forum
Sounds good to me. I can start the process of migrating to SVN.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=31704&messageID=61925#61925
As Don suggested, I would branch xwork 1.x series as it is required for
the upcoming webwork 2.2.3 bugfix release. Trunk/Head will do fine for the
2.0 release then.
What about the proposal of moving over xwork to OpenSymphony SVN repository?
Rainer
> For the 2.0 XWork branch, why not branch off 1.
For the 2.0 XWork branch, why not branch off 1.x so we can keep trunk for
current development? This way, we don't have to change our current checked out
code :)
Don
Patrick Lightbody wrote:
Let's leave XW at OpenSymphony for now - as we know there is a lot of work to
be focussed on when mov
Let's leave XW at OpenSymphony for now - as we know there is a lot of work to
be focussed on when moving a project to Apache and I'd rather not let that
distract us from the core work that needs to be done on Struts. I say in 6
months or so we see about moving it, once we have a SAF 2.0 release
On Sun, 21 May 2006 12:44:02 -0700, Don Brown wrote:
> You can inherit packages and their defined defaults. Therefore, in this
> case, you could define the default interceptor stack and result type for
> a root package then not have to specify it in any action configs of that
> package or child
22 matches
Mail list logo
