Hi,
maybe You are hitting max GET size?
But that's just a guess.
Best greetings,
Paweł Wielgus.
2009/12/1 LS :
>
> Hi All,
>
> I am using Struts2 redirectAction result type as follows -
>
>
> x_viewReport.action
> true
> ${projectId}
> ${contractId}
> ${workOrderId}
> ${contactId}
> ${samplePlan
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 wrote:
> It is good that you brought this up, because the do
Hi All,
I am using Struts2 redirectAction result type as follows -
x_viewReport.action
true
${projectId}
${contractId}
${workOrderId}
${contactId}
${samplePlanId}
${selectionCriteria}
${barcodes}
Barcodes parameter is an user input and if it exceeds 118 barcodes, each
barcode separated
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 change
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 wh
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 th
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 j
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 fin
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 t
On Tue, Dec 1, 2009 at 10:31 AM, Musachy Barroso 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 xwork.
If it
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 Ponta
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 wrote:
> I wouldn't have
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 wrote:
> They'll
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
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 T
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 s
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. Le
17 matches
Mail list logo
