Hi all!
I forgot to remove staging and snapshot section from struts-parent.pom :-(
As I understand, I must rollback release, remove tag and clean up
people.a.o:/www/people.apache.org/builds/struts/2.2.0/ ?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Kapituła Javarsovia 2010
I stuck with this issue during maven release:prepare:
ERROR] Error building bundle
org.apache.struts:struts2-osgi-admin-bundle:bundle:2.2.0 : Input file
does not exist:
target/maven-shared-archive-resources/META-INF/DEPENDENCIES~
[ERROR] Error building bundle
On 6/23/10 8:43 AM, Lukasz Lenart wrote:
Input file does not exist:
target/maven-shared-archive-resources/META-INF/DEPENDENCIES~
target/maven-shared-archive-resources/META-INF/LICENSE~
target/maven-shared-archive-resources/META-INF/NOTICE~
Some editors save backup versions of files in
I've got it :D
http://www.mail-archive.com/d...@felix.apache.org/msg09989.html
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Kapituła Javarsovia 2010 http://javarsovia.pl
-
To unsubscribe, e-mail:
Still something wrong, this time with struts-2.2.0-source-release.zip
- growths over 13 GB!!!
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Kapituła Javarsovia 2010 http://javarsovia.pl
-
To unsubscribe, e-mail:
You should be congratulated on bringing the number of lines of Struts
source up to par with Microsoft Windows.
On Wed, Jun 23, 2010 at 11:01 AM, Lukasz Lenart
lukasz.len...@googlemail.com wrote:
Still something wrong, this time with struts-2.2.0-source-release.zip
- growths over 13 GB!!!
Hi,
I'm ready to make a new Maven release. Is there anything to check /
look before ?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Kapituła Javarsovia 2010 http://javarsovia.pl
-
To unsubscribe, e-mail:
On Saturday 12 December 2009 00:24:41 Dale Newfield wrote:
Gabriel Belingueres wrote:
built-in the web framework
In order to do this we'd need to add in some information in the form and
in every link leading from one page of the form to another so that it's
constantly submitted to the
Who would implement all of these features? So many work and potential bugs...
Maybe it's the way easier to update SWF plugin to version 2?
Gabriel Belingueres-2 wrote:
I also agree that implementing something similar to SWF2 is not very
compelling.
However having implemented
That's what I said. I honestly don't see the point in reinventing the wheel :)
On Tue, Dec 15, 2009 at 7:52 AM, Alex Siman aleksandr.si...@gmail.com wrote:
Who would implement all of these features? So many work and potential bugs...
Maybe it's the way easier to update SWF plugin to version
I have take a look at SWF plugin (http://code.google.com/p/struts2webflow/)
and it seems like that development stopped:
http://code.google.com/p/struts2webflow/issues/detail?id=19
Musachy, I see you in the Project owners. Do you have any plans on that
plugin?
Gabriel, do you have a will to fix
Tom is the owner, he wrote it and gave me access. I was going to fix
it up for SWF 2, but after my struts project got shot down I never
touched it. If anyone wants to help with it let me know, I don't have
any plans to update it myself, but I could help.
musachy
On Tue, Dec 15, 2009 at 9:57 AM,
Alex:
Actually I've chosen the conversations in web applications subject
for my thesis, and I intended to demonstrate a working conversation
implementation using S2 as the code base (nice candidate framework
since it doesn't support them and I have some much experience with it
from my daily work.)
For additional commands, e-mail: dev-h...@struts.apache.org
--
View this message in context:
http://old.nabble.com/struts-2.2-and-guice-tp26594350p26803368.html
Sent from the Struts - Dev mailing list archive at Nabble.com
I also agree that implementing something similar to SWF2 is not very compelling.
However having implemented conversations build it in the framework
have its advantages, mostly because I'm not sure if it can be
implemented/integrated very cleanly/easily writing a third party
plugin.
I was
I have created such wizard:
- simple LRU cache based on HashMap with fixed capacity, say for 5 elems;
- each cache elem collects wizard data;
- this cache stored in user session;
- each request in wizard flow pass the ID - the key of element (wizard data)
in cache;
- when wizard get finished -
This is how most frameworks do it, with continuations. This is essentially
trying to do client side storage on the server. The reason it stores
information like that is because of the Back/Forward buttons and multiple
windows. All of which are client side interactions without a server-side
Seems like you are implementing continuations to me.
But the point I'm trying to make is that if it is already built-in the
web framework, you don't need to do it yourself, and there are
actually production ready frameworks with this kind of functionality.
Gabriel
2009/12/11 Alex Siman
Gabriel Belingueres wrote:
built-in the web framework
In order to do this we'd need to add in some information in the form and
in every link leading from one page of the form to another so that it's
constantly submitted to the server to keep the user associated with the
right conversation.
It would be a lot easier to fix the struts plugin to work with SWF 2.
Reinventing the wheel is evil.
musachy
On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield d...@newfield.org wrote:
Gabriel Belingueres wrote:
built-in the web framework
In order to do this we'd need to add in some information
Wes Wannemacher wrote:
Everything is tied to either the request
or the session, I can't build wizard-style views
Yeah, we need wizards sometimes.
--
View this message in context:
http://old.nabble.com/struts-2.2-and-guice-tp26594350p26728156.html
Sent from the Struts - Dev mailing list
On Thursday 10. December 2009 15.31.15 Alex Siman wrote:
Wes Wannemacher wrote:
Everything is tied to either the request
or the session, I can't build wizard-style views
Yeah, we need wizards sometimes.
I would argue that it would be nice to have, but not a must. Most
| |
+-+
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
--
View this message in context:
http://old.nabble.com/struts-2.2-and-guice-tp26594350p26730390.html
Sent from the Struts - Dev
On Thursday 10. December 2009 17.37.04 Alex Siman wrote:
What if application needs expirable and parallel (say 5 instances at a time)
wizard?
The point is that you have to save the state using the session (or DB or other
persistent storage, but I assume that's more trouble than it's worth)
Granted, most people implement wizards this way, but the most
compelling use of storing state in conversation scope (IMO) is to
allow correct behavior when a user clones a browser window, and then
allow better support for the back button. Even with conversation
support the pages still need to pass
Chris Pratt wrote:
That seems like a very imperfect fix for an almost impossible problem.
Having an extra parameter on the link won't stop a user from right clicking
on the link and saying open in another window and having 2 conversations
with the same conversation key.
If the link followed in
guys, can you start a different thread for this? :)
On Thu, Dec 10, 2009 at 11:27 AM, Gabriel Belingueres
belingue...@gmail.com wrote:
Granted, most people implement wizards this way, but the most
compelling use of storing state in conversation scope (IMO) is to
allow correct behavior when a
On Thursday 10. December 2009 20.27.32 Gabriel Belingueres wrote:
Granted, most people implement wizards this way, but the most
compelling use of storing state in conversation scope (IMO) is to
allow correct behavior when a user clones a browser window, and then
allow better support for the
On Thursday 10. December 2009 20.28.48 Musachy Barroso wrote:
guys, can you start a different thread for this? :)
You have a point there, talk about hijacking a thread:-)
--
Andreas Joseph Krogh andr...@officenet.no
Senior Software Developer / CTO
I think this case is correctly handled in SWF: Each time a request
fires a state transition, SWF saves a continuation of the current
data (think the Memento pattern) Serialized for later use.
When the user right-click the next link opening a new window, the
state transition put the flow in a new
at 12:06 PM, Rene Gielen gie...@it-neering.net
wrote:
I'm a huge fan of moving to Guice 2 internally, although I'm not sure if
we would want to drop the ObjectFactory abstraction for plain pluggable
JSR330 DI - as this would imply that Struts 2.2 would not integrate any
more against Spring 2.x
First, injecting the Container (or Injector as it is called) is allowed in the
JSR and the API is abstracted well enough that it shouldn't cause major
concerns.
On the flip-side, I contend that those instances are broken and can be fixed.
I also don't agree that 330 is too narrow. It should
Don,
I started another thread to talk about the API issue, but for this I
want to give you my take. The Managed Beans JSR I started reading
the other day does offer a few useful features that we don't have. One
is the conversation scope, which I think Struts 2 could really
benefit from. That's
On Tue, Dec 8, 2009 at 11:22 PM, Don Brown mr...@twdata.org wrote:
It isn't about needing a struts-light, it is adding unnecessary
bulk. When I was more active, I spent a lot of time trying to kick
out dependencies, tighten up our weak API's, and overall simplify
interactions with the
On Dec 9, 2009, at 2:47 PM, Wes Wannemacher wrote:
Don,
I started another thread to talk about the API issue, but for this I
want to give you my take. The Managed Beans JSR I started reading
the other day does offer a few useful features that we don't have. One
is the conversation scope,
would be very nice.
On Mon, Dec 7, 2009 at 12:06 PM, Rene Gielen gie...@it-neering.net wrote:
I'm a huge fan of moving to Guice 2 internally, although I'm not sure if
we would want to drop the ObjectFactory abstraction for plain pluggable
JSR330 DI - as this would imply that Struts 2.2 would
be very nice.
On Mon, Dec 7, 2009 at 12:06 PM, Rene Gielen gie...@it-neering.net wrote:
I'm a huge fan of moving to Guice 2 internally, although I'm not sure if
we would want to drop the ObjectFactory abstraction for plain pluggable
JSR330 DI - as this would imply that Struts 2.2 would
In my opinion, current DI support is sufficient (it can be made more
readable, but that's it ;-), I really don't get it what's the problem with
double ObjectFactory issue???
Regards
--
Lukasz
http://www.lenart.org.pl/
I've been loosely following the thread. It sounds like three DI
projects are being/will be supported:
* XWork
* Guice
* JSR-299/JSR-330
Why three? I can understand the last because it's EE, but the other
two are proprietary.
Paul
On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart
JSR 299 is EE while 330 is SE.
-bp
On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote:
I've been loosely following the thread. It sounds like three DI
projects are being/will be supported:
* XWork
* Guice
* JSR-299/JSR-330
Why three? I can understand the last because it's EE, but the
XWork is more than DI. If drives the workflow under the hoods of Struts. We
would need all of that code in addition to the DI. The idea is to drop the DI
part of XWork and replace it with Guice 2.1 (which should support JSR 330) and
just pull in the rest of it.
-bp
On Dec 8, 2009, at 4:32
Since the XWork code is now owned by Apache (right?), you could split
it into two jars (workflow and DI). Then deprecate the DI artifact
unless someone here as aspirations to continue such support. Split in
two, this would hopefully also address Don's concern of the code base
being too big.
I believe that the simplest route would be to collapse everything into a single
core JAR, which includes the workflow and other core APIs. This JAR would would
use the JSR 330 annotations and a provide a couple of Module implementations. I
would then have the Struts servlet filter wire
to drop the ObjectFactory abstraction for plain pluggable
JSR330 DI - as this would imply that Struts 2.2 would not integrate any
more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do
we really expect every Struts2 user and his company will be able to move
to JSR330 compliant DI
On Wed, Dec 9, 2009 at 11:34 AM, Paul Benedict pbened...@apache.org wrote:
Lastly, because Bob Lee is a Struts committer, you should get pretty
good support from him on.
Don't count on it. Bob has moved on from Struts 2, so I would count
on anything beyond moral support. :)
Don
Paul
On
Remember, there are quite a few places that have the Container
instance injected, as they need to query it directly. JSR 330 is too
narrowly scoped to fully abstract DI, as folks like Gavin have been
quick to point out.
Don
On Wed, Dec 9, 2009 at 2:47 PM, Brian Pontarelli br...@pontarelli.com
Don,
JSR 330 is not the magic bullet here.
Agreed, but I would have to say it would be foolish not to support it.
As companies perform internal tech evaluations, people will eventually
realize standard DI injection is not supported: Oh, our company has
to learn XWork DI? What the heck is XWork?
I'm a huge fan of moving to Guice 2 internally, although I'm not sure if
we would want to drop the ObjectFactory abstraction for plain pluggable
JSR330 DI - as this would imply that Struts 2.2 would not integrate any
more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do
we
internally, although I'm not sure if
we would want to drop the ObjectFactory abstraction for plain pluggable
JSR330 DI - as this would imply that Struts 2.2 would not integrate any
more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do
we really expect every Struts2 user and his
the ObjectFactory abstraction for plain pluggable
JSR330 DI - as this would imply that Struts 2.2 would not integrate any
more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do
we really expect every Struts2 user and his company will be able to move
to JSR330 compliant DI within
pluggable
JSR330 DI - as this would imply that Struts 2.2 would not integrate any
more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do
we really expect every Struts2 user and his company will be able to move
to JSR330 compliant DI within the next months? I doubt that, and I'd
internally, although I'm not sure if
we would want to drop the ObjectFactory abstraction for plain pluggable
JSR330 DI - as this would imply that Struts 2.2 would not integrate any
more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do
we really expect every Struts2 user and his
I have talked to a couple of people before and everyone seems to agree
that using guice instead of our internal IoC container (guice pre 1.0
I think), would be a good idea. I don't have any experience with guice
2.0, but looking at the docs it seems like porting our stuff would not
be that hard.
I'd suggest using Guice trunk and the JSR annotations rather than the Guice
annotations. I'd also make the injector pluggable so that people can plug in
Spring/Guice/etc easily.
-bp
On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote:
I have talked to a couple of people before and everyone
good point Brian, that has came up also. I have a couple of concerns
about it, like what is the status of the jsr and will the API
(annotations) will be under a decent (read ASF compatible license)
license and in maven central? which is usually a pain point when it
comes to Sun APIs.
musachy
On
They'll be part of the Guice distribution and under ASLv2 since Guice uses that.
The real question is how to setup the Injector's. I tend to think this layout
would be best:
Base
|
|
_
| |
| |
StrutsApp
I wouldn't have a problem with it as long as I can still swap in my trusty
Spring IoC container, I can't see my team moving away from it any time soon,
but I still want to try to stay as current as possible on Struts.
(*Chris*)
On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli
this is not related to the application itself, you can still use any
IoC you want. This is for the IoC that is used internally to wire
struts internals together, which at the moment is an old version of
guice which is in xwork.
On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com
I don't see a clear distinction between the Struts injector and the
App injector. One thing to keep in mind is that user often request how
to access struts internal stuff, like action mapping etc, which in
theory should not happen, but it does.
musachy
On Tue, Dec 1, 2009 at 10:21 AM, Brian
On Tue, Dec 1, 2009 at 10:31 AM, Musachy Barroso musa...@gmail.com wrote:
this is not related to the application itself, you can still use any
IoC you want. This is for the IoC that is used internally to wire
struts internals together, which at the moment is an old version of
guice which is in
I was actually talking about expanding it out like Chris mentioned. I don't see
any reason why those who want to use the container that Struts is using
shouldn't be able to. Since the annotations and APIs will be standard across
Guice and Spring with the JSR, it seems like it would be possible
I have mixed feelings about it. making it pluggeable is not a priority
I would say. But if there are standard annotations for it now, then
there is no reason why we shouldn't use them. If the day comes when
guice is no longer supported (I don't really mean it crazybob :)), it
would be easier to
Because you don't want to use separate containers. In Guice you can have
child-parent injector relationships. My thought is to just have a single DI
container that builds everything. Struts no longer has any concept of an
ObjectFactory and doesn't create actions or anything like that. It would
ah I see what you mean. yes that would be a good idea, I think that
would work as long as all the containers have what we need, which I am
not sure if it is in the spec or not (havent read it), like:
* create/inject objects and statics (duh)
* lookup all implementation by type
that's all I can
We could probably make a list and verify. I think the API should be pretty
comprehensive about a lot of those things.
-bp
On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote:
ah I see what you mean. yes that would be a good idea, I think that
would work as long as all the containers have
It is good that you brought this up, because the double object factory
is annoying and creates a lot of unexpected situations(problems with
class reloading and OSGi). Having just one container would make it
easier for everybody, users and s2 developers, if it can be pulled
off.
This kind of
I am reading the spec and I am rather impressed, I thought it would be
a simple thing but it is really comprehensive. I doubt we will have a
use case that won't be covered there.
musachy
On Tue, Dec 1, 2009 at 10:49 AM, Musachy Barroso musa...@gmail.com wrote:
It is good that you brought this
to add some ideas that came to my mind lately:
Rework on i18n support
1. create a TextProviderNextGen component that can easily be used and
injected
2. create a TextProvider interceptor which
- sets up a TextProvider
- sets it on an Action implementing TextProviderAware interface
-
We should include/improve a flash result/scope for 2.2:
https://issues.apache.org/struts/browse/WW-2635
an yes, we should start drafting some sort of roadmap.
musachy
On Fri, Apr 24, 2009 at 12:49 PM, Rene Gielen gie...@it-neering.net wrote:
to add some ideas that came to my mind lately:
I have actually been working slowly but steadily on the struts2-jquery
plugin that was discussed awhile back (
http://code.google.com/p/struts2-jquery-plugin). Sorry for the radio
silence. It's now fairly comprehensive and barring after a few TODOs (see
below) , probably ready for some very
Obinna wrote:
Dave Newton updated the patch and applied/assigned to JIRA (
https://issues.apache.org/struts/browse/WW-3009).
All I did was put it into a file so it was usable. If it needs to be
updated then delete the old attachment and attach a new patch file.
Dave
The problem I have is that once the Container is built, there is no
way to register new beans into it. The side effect of this is that
constants and beans that are defined in bundled xml config files
are never loaded into the container. It is the only limitation so far
for the OSGi plugin.
is it possible the JSON plugins as default bundle for S2 2.2
F
On Sun, Apr 12, 2009 at 11:34 PM, Musachy Barroso musa...@gmail.com wrote:
The problem I have is that once the Container is built, there is no
way to register new beans into it. The side effect of this is that
constants and beans
We need for one of the contributors to fax in the CLA. Is that all we need Wes?
musachy
On Sun, Apr 12, 2009 at 12:40 PM, Frans Thamura fr...@meruvian.org wrote:
is it possible the JSON plugins as default bundle for S2 2.2
F
On Sun, Apr 12, 2009 at 11:34 PM, Musachy Barroso
On Sunday 12 April 2009 13:24:51 Musachy Barroso wrote:
We need for one of the contributors to fax in the CLA. Is that all we need
Wes?
musachy
On Sun, Apr 12, 2009 at 12:40 PM, Frans Thamura fr...@meruvian.org wrote:
is it possible the JSON plugins as default bundle for S2 2.2
F
Yes,
Once the plugin is moved over, I am planning to pick the JQuery plugin back
up. Right now there is a datepicker, form submission with validation (via
AJAX)... Are there other features that anyone wants in particular? My goal is
love to hear this good news ;)
F
On Sunday 12 April 2009 14:08:48 you wrote:
Once the plugin is moved over, I am planning to pick the JQuery plugin
back up. Right now there is a datepicker, form submission with validation
(via AJAX)... Are there other features that anyone wants in particular?
My goal is
love to hear
yours jquery will work on top of json plugins, isnt it?
i am waiting the JSON-RPC implementation so we can make S2 as JSONRPC
and REST producer
F
On Mon, Apr 13, 2009 at 1:11 AM, Wes Wannemacher w...@wantii.com wrote:
On Sunday 12 April 2009 14:08:48 you wrote:
Once the plugin is moved over,
On Sunday 12 April 2009 14:32:31 Frans Thamura wrote:
yours jquery will work on top of json plugins, isnt it?
i am waiting the JSON-RPC implementation so we can make S2 as JSONRPC
and REST producer
F
Right now the plugin doesn't require the JSON plugin. It uses the
Right now the plugin doesn't require the JSON plugin. It uses the
JSONValidationInterceptor to handle validation with AJAX form submission. So,
it only depends on core. I didn't want to be dependent on a non-hosted plugin
and figured it was time to bring JSON into the core. I think Musachy and
On Sunday 12 April 2009 14:43:44 Frans Thamura wrote:
Right now the plugin doesn't require the JSON plugin. It uses the
JSONValidationInterceptor to handle validation with AJAX form submission.
So, it only depends on core. I didn't want to be dependent on a
non-hosted plugin and figured it
Now that 2.1 is GA (thanks guys and gals), are we ready to branch it
off and move trunk to 2.2? I was wanting to do some refactoring of
how XWork configuration is loaded and parsed, but new classes and the
like really isn't appropriate for a patch/micro release.
Any objections to the branching?
I think we are good. What changes do you have in mind?, the OSGi
plugin could take advantage of some refactoring of xwork so I am
interested :)
musachy
On Fri, Apr 10, 2009 at 8:24 AM, Don Brown mr...@twdata.org wrote:
Now that 2.1 is GA (thanks guys and gals), are we ready to branch it
off
Off the top of my head:
* Split out the XML parser from XmlConfigurationProvider so that you
can parse XML from any source
* Get rid of all the Class.forName() calls in XWork
I'd rather not do this on a stable branch, particularly since new
public classes will be created. How many changes are
2.1.7 has bug fixes and some small changes in Convention, nothing big.
musachy
On Fri, Apr 10, 2009 at 9:35 AM, Don Brown mr...@twdata.org wrote:
Off the top of my head:
* Split out the XML parser from XmlConfigurationProvider so that you
can parse XML from any source
* Get rid of all the
I forgot to say, we can roll a build without trouble, we just need to
release xwork first (I don't think there is any blocker for xwork).
musachy
On Fri, Apr 10, 2009 at 4:02 PM, Musachy Barroso musa...@gmail.com wrote:
2.1.7 has bug fixes and some small changes in Convention, nothing big.
86 matches
Mail list logo
