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
noti
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
, 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 Ponta
> Again, there are significant costs to this proposal, and I have yet to
> hear a substantial, real-world benefit. Earlier, we went so far as to
> define our own logging API because we wanted to keep that boundary
> between the app and the framework. Sometimes, strict boundaries are
ations to continue such support. Split in
> two, this would hopefully also address Don's concern of the code base
> being too big.
>
> Lastly, because Bob Lee is a Struts committer, you should get pretty
> good support from him on.
>
> Paul
>
> On Tue, Dec 8,
, Paul Benedict wrote:
> Then what was the point of getting the IP for XWork?
>
> On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli wrote:
>> JSR 299 is EE while 330 is SE.
>>
>> -bp
>>
>>
>> On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote:
>&
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 th
wrote:
>>>>>> 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.
>>>>>>
>>&g
It looks like this code is against the JEE WebBeans injection stuff (299). The
JSR that Guice will be implementing is 330, which is a JSE injection model.
-bp
On Dec 7, 2009, at 9:35 AM, Wes Wannemacher wrote:
> Is this 299 or 330? I have been meaning to read the spec, and this
> confused me..
s 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 think off the top of my head.
>
> musachy
>
> On Tue,
tainer, 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:
>>>
>>>>
s possible on Struts.
>> (*Chris*)
>>
>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli
>> wrote:
>>
>>> They'll be part of the Guice distribution and under ASLv2 since Guice uses
>>> that.
>>>
>
compatible license)
> license and in maven central? which is usually a pain point when it
> comes to Sun APIs.
>
> musachy
>
> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli wrote:
>> I'd suggest using Guice trunk and the JSR annotations rather than the Guice
>> ann
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
can get some folks to look at it. With the parameters problem solved,
the rest is not *that* hard.
On Tue, Nov 3, 2009 at 10:00 AM, Brian Pontarelli > wrote:
I still think that the simplest approach is still to do nothing
except for
EL and let the view technology do it all (JSP, FTL, VM, et
I still think that the simplest approach is still to do nothing except
for EL and let the view technology do it all (JSP, FTL, VM, etc.). The
only time you need anything remotely similar to EL is for getting and
setting values out of beans. This is generally not EL handling, but
basic JavaB
On Oct 23, 2009, at 10:10 AM, Christian Stone wrote:
On Oct 23, 2009, at 12:01 PM, Brian Pontarelli wrote:
I've done some work with it and it looks to be completely
pluggable. I do this same thing in JCatapult with other libraries.
Essentially, I define a workflow chain
bad (presuming the core
architecture is in place)! If the convention of Struts is to
configure and deploy everything, including JSP dispatcher, etc. then
I love the idea!
-- Christian
On Oct 23, 2009, at 11:13 AM, Brian Pontarelli wrote:
I was never big on the Servlet or Filter mo
I was never big on the Servlet or Filter models. It seems to me that
Struts2 is moving heavily towards conventions and the more things are
just "pluggable" the easier it will be for users. I feel that the best
approach would be for Struts2 to discover SiteMesh in the class path
and wire it
From my conversations with Joe, integration will be much simpler with
the next version. I'm looking at using the next version so that all
the templates are FreeMarker and I will be able to create my own
FreeMarker root context. It also looked like everything was going to
be extendable or ov
I just finished a massive license audit for some internal things. It
is an enormous pain. GPL is incompatible with ASL because of the
redistribution portions of the licenses. ASL lets you redistribute
without any restrictions. This allows commercial software to ship ASL
Jar files inside the
Actually, I think this is in regards to the JSF validation attributes
yo can specify on the JSF tags. I believe that this either does some
serialization magic or some session magic to connect the attributes
specified on the tags with the server-side validator. I think it looks
like:
Does this plugin provide for executing the JSPs in unit tests?
Embedding is really nice, but unit testing is even better.
-bp
On Aug 13, 2009, at 12:27 PM, Wes Wannemacher wrote:
I think it is a good idea, as much as I dislike JSP (because it is so
non-portable, which this very plugin addre
Why so hesitant to do another release? It has been a long time since
2.0. I think it is time for some major rework and releasing a new
major version.
Sent from my iPhone
On Aug 12, 2009, at 8:06 PM, Don Brown wrote:
On Thu, Aug 13, 2009 at 12:01 PM, Paul
Benedict wrote:
Are you sure it's
Except the API changes. Remember that any API change that breaks
someone should be a major release. That's why people work so hard on
keeping old APIs around.
Sent from my iPhone
On Aug 12, 2009, at 3:45 PM, Wendy Smoak wrote:
On Wed, Aug 12, 2009 at 2:36 PM, Paul Benedict
wrote:
I defin
On Aug 10, 2009, at 11:52 PM, Don Brown wrote:
On Tue, Aug 11, 2009 at 3:38 PM, Paul Benedict
wrote:
On Tue, Aug 11, 2009 at 12:22 AM, Don Brown
wrote:
By forking XWork, we can a) bring core Struts 2 code into the
project
where it belongs and b) still leave it available for other users
Personally, I feel that struts top to bottom should be web centric and
not try to abstract out JEE. This makes life cumbersome and difficult
in many cases. Often this also leads to hacking interfaces or writing
tricky new semantics on top of more general interfaces in order to get
access to
I'm all for this ;) (http://markmail.org/message/nykgr354ts4hlkif)
-bp
On Aug 5, 2009, at 11:12 PM, Don Brown wrote:
XWork was left at OpenSymphony, because at the time, there were a
number of WebWork developers still around and we wanted to continue to
work together. Today, WebWork activity
alues, you can use
asm easily:
http://svn.opensymphony.com/svn/xwork/branches/parameter-binder/core/src/main/java/com/opensymphony/xwork2/parameters/bytecode/AccessorBytecodeUtil.java
musachy
On Mon, Jul 6, 2009 at 10:41 AM, Brian
Pontarelli wrote:
I sorta figured it would be pretty slow. You
d bytecode generation for setters/getters.
is your EL decoupled fro jcatapult?
musachy
On Mon, Jul 6, 2009 at 10:13 AM, Brian
Pontarelli wrote:
I would say the reason you don't want to dive into 233 would be
primarily
because of performance. You'd either need to have a compiled
st
I would say the reason you don't want to dive into 233 would be
primarily because of performance. You'd either need to have a compiled
statement cache or pre-compile. Most of the scripting frameworks that
comply with 233 are full blow languages (Groovy, JavaScript, etc) and
have pretty slow
th the
company number 6741909. The registered head office is Kemp House,
152-160 City Road, London, EC1V 2NX, UK.
The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.
-Original
Interesting. On the Guice list there is another thread about GAE. You
should submit a bug for Sitemesh to Google and to the Sitemesh
maintainers. Google seems to be up for fixing some of these issues.
This one looks like either a JNDI bug or JNDI security measure (my
guess is the later). Ei
() {
return start.toDate();
}
public void setStartDate(Date start) {
this.start = new DateTime( start) ;
}
Si quieres ser más positivo, pierde un electrón
Miguel Ruiz Velasco S.
On Wed, Dec 17, 2008 at 09:46, Brian Pontarelli
wrote:
Date is pretty much
Date is pretty much deprecated except for a way to carry a long
primitive around because of the TZ and conversions it lacks. It fails
in some cases and most of the core API on Date is deprecated. Most
folks should be using Calendar for date and time correctness if they
don't want to use Jod
Anyone that had contacted Garrett about MSDN subscriptions, I talked
with MSDN support the other day and it looks like the subscriptions
were created on 10/31, just not activated and associated with each
persons account. I sent Garrett an email this morning to inquire and
I'll let you all
* OGNL - Is is staying? Is it going? Can it be secure? Is it fast
enough?
I say drop it completely. No more evaluation in the JSPs or FTL files
at all and use MVEL for the parameters interceptor. FTL has a good
enough language and you have Java in JSPs if you need it. OGNL in
there is
t to pollute the Struts mailing list with non-Struts related talk.
Brian Pontarelli wrote:
Not sure I follow. If I compile an expression, how can I reuse the
compiled version? I would assume it would need to be in a cache where
the key is the expression String and the value is the compiled
version.
ying to recreate the conditions of this.
Brian Pontarelli wrote:
Sure. But OGNL will return similar results with 50 tests. Yet
people have
run into performance problems. The issue is that you're not looking
at
performance in terms of resource contention, and in terms of
aggregate
therwise as there
is in
things like Commons EL, or JEXL. This is actually, from an
architectural
perspective what makes MVEL stand apart from these technologies.
Brian Pontarelli wrote:
Sure. But OGNL will return similar results with 50 tests. Yet
people have
run into performance probl
Sure. But OGNL will return similar results with 50 tests. Yet
people have
run into performance problems. The issue is that you're not looking
at
performance in terms of resource contention, and in terms of aggregate
resource usage.
I'd say that for web application expressions OGNL and MVE
erializable s = MVEL.compileExpression("foo.bar");
long start = System.currentTimeMillis();
for (int i = 0; i < iterations; i++) {
MVEL.executeExpression(s, entityObj);
}
System.out.println("compiled time: " + (System.currentTimeMillis()-
start));
Brian Pontarelli wrote:
Se
in
in the
butt to test in isolation.
Brian Pontarelli wrote:
We could do that if you like. Those are pretty simple numbers with
very straight-forward cases. So, please run those against MVEL and
let
me know what you get. StringTokenizer is obviously quite fast, and I
could easily remove it
u say) it's not generic, and a bit of a pain
in the
butt to test in isolation.
Brian Pontarelli wrote:
We could do that if you like. Those are pretty simple numbers with
very straight-forward cases. So, please run those against MVEL and
let
me know what you get. StringTokenizer is obvio
-patterns, instead of
heavyweight configuration sessions which would completely bog down
the
performance.
http://artexpressive.blogspot.com/2007/11/juel-vs-mvel.html
For an example of how performant MVEL's interpreter is with no
factory
caching.
In a simple property expression, with no cachi
ly efficient sliding-window parser.
Brian Pontarelli wrote:
Right, but you can receive similar or better performance using a
linear runtime evaluation if the language is simple enough and tuned
for the web. And as you and I say, MVEL and most other languages
aren't targeted to the web and hav
before
executing every time), MVEL was able to parse/reduce the expression
"foo.bar" 100,000 times in 94ms. It took JUEL 2749ms to do the same.
Compiled performance was: 5.8ms to 34.2ms in favor of MVEL too.
So I would err on the side of performance here. If that doesn't cut
it fo
conversion API, just like OGNL. Since it's
source-from-many in it's design, you can easily design converters that
perform as much introspection as necessary to determine formatting,
etc.
Brian Pontarelli wrote:
Yeah. That's good. The last thing I would toss in as criteria is a
go
's
compiler can certainly extract the generic type information, and
provide
automatic coercion and verification accordingly. MVEL's type
verifier will
always extrapolate whatever type data is available.
Brian Pontarelli wrote:
This is not quite the same unless it can detect generics whil
quot;value1,value2,value3"}
rather than
{"value1", "value2", "value3"}
This was a while ago, so all of this might be fixed.
-bp
On Oct 9, 2008, at 7:32 PM, Chris Brock wrote:
MVEL 2.0 has full support for generics (and static typing):
http://mvel.code
On Oct 7, 2008, at 3:08 PM, Dave Newton wrote:
Just to muddy the EL/templating waters:
http://mvel.codehaus.org/Performance+of+MVEL
(v. OGNL)
Not sure about MVEL or OGNL at this point, but everything was lacking
in support for generics, collections and arrays. I wrote my own for
the JCa
As I'm never a big fan of relying solely on the fact that technologies
have been "used", I'd compare feature sets. Here's what I like from GXP:
- Pre-compile for performance
- Type safe
- Injectable
- White space reduction
- l10n and i18n support (although difficult to determine exactly how
t
IJ 8.0 has built in FTL support. EAPs are currently available.
-bp
On Jul 27, 2008, at 8:36 AM, Rene Gielen wrote:
I Like it very much, from what I can tell from a first glance. In
addition to the interesting features, it should be nice to work with
an
IDE like IDEA (which still lacks fm s
I wrote my own for the JCatapult MVC and it does most of the parameter
setting stuff that OGNL does and a few other things like handling
generics correctly and completely. It also has a pretty solid type
conversion API. Took about 3 days to write, test and complete. Feel
free to grab the co
Just to update this thread quick...
The error is occurs mostly because the perm size is filling up or the
loading of a specific class is causing the ClassLoader to error out.
This the primary reason why I added the exclusions list. The other
reason is that scanning the entire classpath and
I think we both agree that configuration is best. In fact I think you
even support environment awareness in configuration system. So, from
that perspective we are solid. The rest is just debating personal
style and developer freedom. I will answer a few things below, but I
think we can cl
I've kind of lost track of the original point anyway :/
Al mentioned that adding environment awareness to JSF makes people
lazy. I jumped in and stated I disagreed and that adding this just
allows people that need it to use it. From what I've gathered thus far
(Al correct me if I'm wrong),
lysis. Your situation might call for
certain things but saying that adding environmental awareness to JSF
makes people lazy is rather short-sighted in my opinion.
-bp
Al.
Brian Pontarelli wrote:
I've written code that uses environment. Of course, I mainly write
frameworks, so
t;dev, test, or prod" switch how
could they have done that?
Yes configuration is a feature of the environment, but it should be
up to the environment manager to manage the configuration, and not
up to the developer to dictate what is correct.
Al.
Brian Pontarelli wrote:
Wow. This got
All in all it does seem like a lazy solution to me, whats needed is
better QA, not a solution which makes people sloppy because they
think that the code will catch their mistakes.
Al.
Brian Pontarelli wrote:
I think this is an over-simplification of a complex problem. Here
are
t sure if there would be enough interest.
(*Chris*)
On Fri, Jun 27, 2008 at 1:38 PM, Brian Pontarelli <[EMAIL PROTECTED]
> wrote:
Yeah, I found that environment resolution was a key feature for
any large
application. At Orbitz we could deploy the same bundle to any
server and the
bu
Yeah, I found that environment resolution was a key feature for any
large application. At Orbitz we could deploy the same bundle to any
server and the bundle would figure out where it was and configure
itself for that environment. Worked really well.
I have also provided this type of featur
Al Sutton wrote:
Brian,
Dependencies can be reduced to simple ordered lists unless there is a
requirement for two plugins to be run in parallel (which is pretty
rare), or you have a circular dependency. Reduction of dependency
graphs is something I've come accros dependency declaration handli
e, lets not complicate it much. I think the UnknowHandler
problem calls for an easy solution, and over-architecturing the whole
thing would be bad. BTW, specifying the order in which plugins will be
loaded wouldn't solved the UnknowHandler problem.
my 2 pesos :)
musachy
On Tue, Jun 3, 2008
#x27;s
useful to be able to specify an order.
Al.
Musachy Barroso wrote:
I like Dusty's suggestion, or something like it:
musachy
On Mon, Jun 2, 2008 at 2:36 PM, Brian Pontarelli
<[EMAIL PROTECTED]> wrote:
Not yet. Just thinking about how I'm going to pull
out dynamically or
some type of integer based indexing for each Workflow, but these all
seem pretty lame.
-bp
Musachy Barroso wrote:
Do you have an implementation of this already?
musachy
On Mon, Jun 2, 2008 at 1:21 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
Musachy Barros
Musachy Barroso wrote:
For those of you ignoring the spam on the Convention vote thread :). I
mentioned that the framework should support more than one
UnknownHandler, which would eventually make Convention and Codebehind
compatible, as well as other plugins in the future. The bad side
effect is
Secondly, I was wondering about the advantages of having fewer
dependencies, especially in this maven era. If something's really
great, it's fine to depend on it, surely?
And there is still a large number of folks using Ant, Ivy and Savant.
-bp
-
n" is one of them
musachy
On Thu, May 29, 2008 at 11:47 AM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
Just a quick question. How did you modify ClasFinder to check for
implementation of the XWork Action interface? Doesn't this need to parse up
the inheritance chain as well
Just a quick question. How did you modify ClasFinder to check for
implementation of the XWork Action interface? Doesn't this need to parse
up the inheritance chain as well as the implementation chain? It didn't
look like ClassFinder currently did that, unless I missed it.
-bp
Musachy Barro
it's all Apache license and only 3 classes so we could just pull it into
XWork and manage it there.
On Wed, May 28, 2008 at 3:24 PM, dusty <[EMAIL PROTECTED]> wrote:
>
> If you already have it working, then great! I don't know anything about
> it,
> so my question is only how likely are the auth
Musachy Barroso wrote:
The scanning doesn't have anything to do with the location of the JSP files.
It is entirely based on the set of package locators and exclude packages. It
uses the classpath scanning mechanism that simply opens all the JAR files
and looks at them. It only loads a class into
Musachy Barroso wrote:
The plugin will scan the entire classpath, but that's not to large of an
issue and pretty fast (considering). The issue is when it starts loading
classes into the perm space to determine if the class is in fact an Action
or not. This is the part where your perm space can be
The plugin will scan the entire classpath, but that's not to large of an
issue and pretty fast (considering). The issue is when it starts loading
classes into the perm space to determine if the class is in fact an
Action or not. This is the part where your perm space can become full
and then yo
BTW, I'd like to thank Musachy for taking charge of this. Having started
my own company in Feb. I have barely had time for anything open source.
Hopefully this can make it over and users can jump on board with it. It
really makes Struts2 development so much simpler and JCatapult is
essentiall
+1
Here are the goals of this plugin. Any movement to integrate plugins and
make all things compatible (which I gracefully disagree with) MUST
satisfy these goals:
- Simple API that is fixed and will not change anytime soon
- Usable with absolutely no configuration or annotations
- M
assignee's. All is well now.
-bp
Musachy Barroso wrote:
Done
On Tue, May 13, 2008 at 10:58 AM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
Agreed.
Musachy Barroso wrote:
Another thing is that the convention plugin is using
java.util.logging.*. I think we should stick
the project
> now from svn
> >> > > and I' m running into issues with the missing parent pom.
> >> > >
> >> > > Any help getting this into the next release would be greatly
> appreciated :)
> >> > >
> >> > > Also, does this plugin effe
t pom.
> >
> > Any help getting this into the next release would be greatly
appreciated :)
> >
> > Also, does this plugin effectively make codebehind and
smarturls obsolete?
> >
> > Thanks again.
> > --
Musachy Barroso wrote:
I think FilterDispatcher should be changed to allow other
implementations to lookup static resources and be more flexible in
general. As it stands right now, static resources cannot be served
from plugins unless you put them in org.apache.struts2.static in a jar
loaded by
t the API level can't be
solved by a tool. This problem is a compile time problem that needs to
be handled by developers. OSGi is a runtime dynamic loader, not a
compile time dynamic method binder or a runtime dynamic method
invocation layer.
-bp
Don
On Sat, Apr 26, 2008 at 3:45 AM, Brian
Jeromy Evans wrote:
Putting aside the technology for a moment:
- ability to deploy new actions/replace actions and pages without a
container restart: highly desirable
Only at development stage right? There are tools that use JDPA and other
methods to do this with Struts and other frameworks. Ho
uot; and everything should work. This is
the ultimate definition of compatibility and something I feel Struts
needs to start ensuring.
-bp
/Ian
Brian Pontarelli wrote:
Yours and mine are the same because you still have implementations
inside Struts for some of the API interfaces. For exam
. I also agree with Brian that
there will be a burden on s2 to provide the necessary features for all
APIs, but I think it's less of a burden in this layout.
/Ian
Brian Pontarelli wrote:
Here's a few things I think about when considering API versioning:
1. How many implementors
Here's a few things I think about when considering API versioning:
1. How many implementors are there? It sounds like there will be one -
Struts2
2. Do you want to allow implementors to implement multiple APIs? Sounds
like yes.
3. How much is shared between APIs? Probably a lot.
From what it
Bob Tiernay wrote:
Anyone know what the status of the Convention plugin is? Is there
anyways we can get it out of the sandbox and into a formal release?
I'm willing to help out :)
The plugin is stable and running in production. It can probably be moved
out of the sandbox whenever we want. At t
You can definitely inject from any of the XWork files,
struts-default.properties, struts.properties, struts.xml,
struts-default.xml, struts-plugin.xml. These are all configured in the
Dispatcher when the Container is created (I think).
-bp
Musachy Barroso wrote:
I tried that, I think the p
Yeah, I was hoping to have time to get the convention plugin into the
main repository, but I just haven't had anytime at all. It will have to
wait until 2.2 unless someone else wants to move it over. At this point
I can't even recall the outstanding issues and design changes that were
being dis
Haroon Rafique wrote:
On Yesterday at 11:37am, BP=>Brian Pontarelli <[EMAIL PROTECTED]> wrote:
BP>
BP> BTW, some of the JetBrains folks said that FreeMarker support will be
BP> in 8 and should be available in EAP soon! This will definitely help
BP> move me farther away
BTW, some of the JetBrains folks said that FreeMarker support will be in
8 and should be available in EAP soon! This will definitely help move me
farther away from JSPs. :)
-bp
Jeromy Evans wrote:
Jonathan Revusky wrote:
Thanks for the detailed argument Jonathon.
Jeromy Evans wrote:
Nia
Here's my list:
- Collapse XWork into Struts
- Rewrite XWork to be a servlet workflow engine and less abstract (i.e.
remove thread locals and contexts)
- Fix nasty circular XWork injections and setter injections
- Generics
- Update all public APIs no matter how infrequently used and then hard
- Overhaul message passing so that action errors and action messages
could be persisted through redirects with no user configuration or
validation issues.
Scopes plugin works pretty well from what I've heard.
- Overhaul zero configuration to allow results to be defined at method
level
Conve
Can someone that has a lot of experience with ValueStack evaluation help
me get a test working? The test in question is currently commented out
at the bottom of the UIBeanTest.
The purpose is to verify that if the 'key' attribute contains any single
quotes they are correctly escaped prior to O
Dale Newfield wrote:
Chris Pratt wrote:
The proposed flow (with false
The bit you're missing is that if you have a tag attribute with
rtexprvalue set to false that contains what the container thinks is an
EL expression (i.e., "${foo}"), the jsp compilation will fail, so it
will never execute
David Durham, Jr. wrote:
On Thu, Mar 6, 2008 at 2:42 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
You can't put things into Maps that have wildcards. The compiler
complains because Object really isn't '?'. Although most language
pragmatist would tell you it is
Correct me if I'm wrong but I believe that restricts the map to only
accepting values that are exactly Object. It will not allow things
that extend Object, only Object themselves. You could use:
Map
Which is just a long-hand way of saying:
May
You can't put things into Maps that have wil
There are two discussions going on here that could probably be split:
1. OGNL vs. JUEL
2. Taglibs
#1 has already come up a number of times and I believe that there is
enough support to move the JUEL plugin forward and start removing OGNL
once a roadmap is clear. The wiki page Dale pointed to i
Wendy Smoak wrote:
On Sun, Feb 24, 2008 at 1:04 AM, Don Brown <[EMAIL PROTECTED]> wrote:
Unfortunately, my computer is experiencing severe stability problems,
so the Struts 2.1.1 build will be delayed. I'm hoping to give it a
shot next weekend. Of course, anyone is free to give it a go in
Piero Sartini wrote:
Am Freitag, 22. Februar 2008 00:05:53 schrieb Don Brown:
Yes, you are missing my original point #2 - "We need to be able to do
"alpha" releases to get new, experimental features into the community
for testing." I need a way to create an alpha release for 2.1 to hand
off t
Al Sutton wrote:
Antonio,
I see where you're coming from, but I really don't think the leap from
S2.0 to the current S2.1 is anywhere near the leap from S1 to S2,
hence why I'm in favour of the 2.1 because I feel it reflects that
although there are some changes, many of the core concepts are
1 - 100 of 298 matches
Mail list logo
