Re: [Resin-interest] Question about Resin 4.0.6
I don't know if there is a way and it isn't something I'd depend on in the
UI layer. Think of [class] like you'd think of an interface. You really
should only put implementations of interfaces into the context. Otherwise,
I'd consider putting a Map in there for the effect you want.
jon
On Fri, May 7, 2010 at 1:43 PM, Aaron Freeman aaron.free...@layerz.comwrote:
Bummer, what's the proper way to test if a property exists then, since
${!empty [class].[property]} isn't the correct way?
Thanks,
Aaron
On 5/7/2010 3:07 PM, Jon Stevens wrote:
That is what JBoss does, so I'd say that Caucho fixed a bug.
jon
On Fri, May 7, 2010 at 12:59 PM, Aaron Freeman
aaron.free...@layerz.comwrote:
We are system testing Resin 4.0.6 with our old code base and found a
curiosity. The following code used to work, regardless of what type
receipt is:
c:if test=${!empty receipt.details}
Under Resin 3.0.x if receipt was a HashMap and had a details property
then it would return true. If it was a HashMap and did not have a
details property, it would correctly return false. And (most
importantly), if receipt was _any_ other class, including built in java
classes, it would just return false. With Resin 4.0.6 it now throws an
error:
'details' is an unknown bean property of 'java.math.BigDecimal'
That's not the expected behavior is it?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question about Resin 4.0.6
This isn't in the UI layer. This is in a controller. At any rate there
is a simple work around, but this sure doesn't seem like it should be
generating an error. If a property doesn't exist on an object it sure
seems like the test for empty=true should work, and not throw a runtime
error.
At any rate there are easy workarounds in this case but workarounds make
the code uglier.
Aaron
On 5/7/2010 3:57 PM, Jon Stevens wrote:
I don't know if there is a way and it isn't something I'd depend on in
the UI layer. Think of [class] like you'd think of an interface. You
really should only put implementations of interfaces into the context.
Otherwise, I'd consider putting a Map in there for the effect you want.
jon
On Fri, May 7, 2010 at 1:43 PM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
Bummer, what's the proper way to test if a property exists then,
since ${!empty [class].[property]} isn't the correct way?
Thanks,
Aaron
On 5/7/2010 3:07 PM, Jon Stevens wrote:
That is what JBoss does, so I'd say that Caucho fixed a bug.
jon
On Fri, May 7, 2010 at 12:59 PM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
We are system testing Resin 4.0.6 with our old code base and
found a
curiosity. The following code used to work, regardless of
what type
receipt is:
c:if test=${!empty receipt.details}
Under Resin 3.0.x if receipt was a HashMap and had a
details property
then it would return true. If it was a HashMap and did not
have a
details property, it would correctly return false. And (most
importantly), if receipt was _any_ other class, including
built in java
classes, it would just return false. With Resin 4.0.6 it now
throws an
error:
'details' is an unknown bean property of 'java.math.BigDecimal'
That's not the expected behavior is it?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question about Resin 4.0.6
I've always written code that assumes empty returns false if the property
doesn't exist. I haven't checked the spec, but throwing an exception seems like
the wrong thing to do.
--
Rick
On May 7, 2010, at 14:47:21, Aaron Freeman wrote:
This isn't in the UI layer. This is in a controller. At any rate there is a
simple work around, but this sure doesn't seem like it should be generating
an error. If a property doesn't exist on an object it sure seems like the
test for empty=true should work, and not throw a runtime error.
At any rate there are easy workarounds in this case but workarounds make the
code uglier.
Aaron
On 5/7/2010 3:57 PM, Jon Stevens wrote:
I don't know if there is a way and it isn't something I'd depend on in the
UI layer. Think of [class] like you'd think of an interface. You really
should only put implementations of interfaces into the context. Otherwise,
I'd consider putting a Map in there for the effect you want.
jon
On Fri, May 7, 2010 at 1:43 PM, Aaron Freeman aaron.free...@layerz.com
wrote:
Bummer, what's the proper way to test if a property exists then, since
${!empty [class].[property]} isn't the correct way?
Thanks,
Aaron
On 5/7/2010 3:07 PM, Jon Stevens wrote:
That is what JBoss does, so I'd say that Caucho fixed a bug.
jon
On Fri, May 7, 2010 at 12:59 PM, Aaron Freeman aaron.free...@layerz.com
wrote:
We are system testing Resin 4.0.6 with our old code base and found a
curiosity. The following code used to work, regardless of what type
receipt is:
c:if test=${!empty receipt.details}
Under Resin 3.0.x if receipt was a HashMap and had a details property
then it would return true. If it was a HashMap and did not have a
details property, it would correctly return false. And (most
importantly), if receipt was _any_ other class, including built in java
classes, it would just return false. With Resin 4.0.6 it now throws an
error:
'details' is an unknown bean property of 'java.math.BigDecimal'
That's not the expected behavior is it?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question about Resin 4.0.6
This comment isn't helpful I know but I am very curious about this.
The code you quoted is a tag library call using the EL. How is that
not part of the UI? Are you writing controllers in JSP somehow?
Rachel
On Fri, May 7, 2010 at 2:47 PM, Aaron Freeman aaron.free...@layerz.com wrote:
This isn't in the UI layer. This is in a controller. At any rate there is
a simple work around, but this sure doesn't seem like it should be
generating an error. If a property doesn't exist on an object it sure seems
like the test for empty=true should work, and not throw a runtime error.
At any rate there are easy workarounds in this case but workarounds make the
code uglier.
Aaron
On 5/7/2010 3:57 PM, Jon Stevens wrote:
I don't know if there is a way and it isn't something I'd depend on in the
UI layer. Think of [class] like you'd think of an interface. You really
should only put implementations of interfaces into the context. Otherwise,
I'd consider putting a Map in there for the effect you want.
jon
On Fri, May 7, 2010 at 1:43 PM, Aaron Freeman aaron.free...@layerz.com
wrote:
Bummer, what's the proper way to test if a property exists then, since
${!empty [class].[property]} isn't the correct way?
Thanks,
Aaron
On 5/7/2010 3:07 PM, Jon Stevens wrote:
That is what JBoss does, so I'd say that Caucho fixed a bug.
jon
On Fri, May 7, 2010 at 12:59 PM, Aaron Freeman aaron.free...@layerz.com
wrote:
We are system testing Resin 4.0.6 with our old code base and found a
curiosity. The following code used to work, regardless of what type
receipt is:
c:if test=${!empty receipt.details}
Under Resin 3.0.x if receipt was a HashMap and had a details property
then it would return true. If it was a HashMap and did not have a
details property, it would correctly return false. And (most
importantly), if receipt was _any_ other class, including built in java
classes, it would just return false. With Resin 4.0.6 it now throws an
error:
'details' is an unknown bean property of 'java.math.BigDecimal'
That's not the expected behavior is it?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question about Resin 4.0.6
I doublechecked the spec and the current Resin behavior is the proper
behavior. I don't think this behavior has changed in the spec, so the
old behavior was a bug. You can't use the empty operator to test for
the existence of fields (or methods).
As to the rationale for the spec... it does make some amount of sense,
helping to reduce one very common type of bug (I'm getting properties
of a ThingA and the object turns out to be a ThingB). I'm sure all
the arguments for static typing vs duck typing apply here.
Note: There is nothing special about the empty operator; expressions
are resolved as normal and then the result is tested for null or empty
collection. If expression evaluation ever tries to access a field or
method that doesn't exist on an object, the EL resolver throws
PropertyNotFoundException or MethodNotFoundException.
Jeff
On Fri, May 7, 2010 at 2:47 PM, Aaron Freeman aaron.free...@layerz.com wrote:
This isn't in the UI layer. This is in a controller. At any rate there is
a simple work around, but this sure doesn't seem like it should be
generating an error. If a property doesn't exist on an object it sure seems
like the test for empty=true should work, and not throw a runtime error.
At any rate there are easy workarounds in this case but workarounds make the
code uglier.
Aaron
On 5/7/2010 3:57 PM, Jon Stevens wrote:
I don't know if there is a way and it isn't something I'd depend on in the
UI layer. Think of [class] like you'd think of an interface. You really
should only put implementations of interfaces into the context. Otherwise,
I'd consider putting a Map in there for the effect you want.
jon
On Fri, May 7, 2010 at 1:43 PM, Aaron Freeman aaron.free...@layerz.com
wrote:
Bummer, what's the proper way to test if a property exists then, since
${!empty [class].[property]} isn't the correct way?
Thanks,
Aaron
On 5/7/2010 3:07 PM, Jon Stevens wrote:
That is what JBoss does, so I'd say that Caucho fixed a bug.
jon
On Fri, May 7, 2010 at 12:59 PM, Aaron Freeman aaron.free...@layerz.com
wrote:
We are system testing Resin 4.0.6 with our old code base and found a
curiosity. The following code used to work, regardless of what type
receipt is:
c:if test=${!empty receipt.details}
Under Resin 3.0.x if receipt was a HashMap and had a details property
then it would return true. If it was a HashMap and did not have a
details property, it would correctly return false. And (most
importantly), if receipt was _any_ other class, including built in java
classes, it would just return false. With Resin 4.0.6 it now throws an
error:
'details' is an unknown bean property of 'java.math.BigDecimal'
That's not the expected behavior is it?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question about Resin 4.0.6
On May 7, 2010, at 15:39:37, Jeff Schnitzer wrote:
Note: There is nothing special about the empty operator; expressions
are resolved as normal and then the result is tested for null or empty
collection. If expression evaluation ever tries to access a field or
method that doesn't exist on an object, the EL resolver throws
PropertyNotFoundException or MethodNotFoundException.
Yeah, that makes sense.
Jeff
On Fri, May 7, 2010 at 2:47 PM, Aaron Freeman aaron.free...@layerz.com
wrote:
This isn't in the UI layer. This is in a controller. At any rate there is
a simple work around, but this sure doesn't seem like it should be
generating an error. If a property doesn't exist on an object it sure seems
like the test for empty=true should work, and not throw a runtime error.
At any rate there are easy workarounds in this case but workarounds make the
code uglier.
Aaron
On 5/7/2010 3:57 PM, Jon Stevens wrote:
I don't know if there is a way and it isn't something I'd depend on in the
UI layer. Think of [class] like you'd think of an interface. You really
should only put implementations of interfaces into the context. Otherwise,
I'd consider putting a Map in there for the effect you want.
jon
On Fri, May 7, 2010 at 1:43 PM, Aaron Freeman aaron.free...@layerz.com
wrote:
Bummer, what's the proper way to test if a property exists then, since
${!empty [class].[property]} isn't the correct way?
Thanks,
Aaron
On 5/7/2010 3:07 PM, Jon Stevens wrote:
That is what JBoss does, so I'd say that Caucho fixed a bug.
jon
On Fri, May 7, 2010 at 12:59 PM, Aaron Freeman aaron.free...@layerz.com
wrote:
We are system testing Resin 4.0.6 with our old code base and found a
curiosity. The following code used to work, regardless of what type
receipt is:
c:if test=${!empty receipt.details}
Under Resin 3.0.x if receipt was a HashMap and had a details property
then it would return true. If it was a HashMap and did not have a
details property, it would correctly return false. And (most
importantly), if receipt was _any_ other class, including built in java
classes, it would just return false. With Resin 4.0.6 it now throws an
error:
'details' is an unknown bean property of 'java.math.BigDecimal'
That's not the expected behavior is it?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question about Resin 4.0.6
Yes, that's exactly right. In several instances we have many
controllers that are written in JSP (pure JSTL code), that c:import
our models (also in this case JSPs) and also c:import our views.
Works great!
The upside to it is: a) easier to code -- people with limited Java
expertise can modify the controllers if they are not too complex (and
rarely are), and b) you can change your controllers on the fly without
having to restart Resin (primary reason we do this).
Aaron
On 5/7/2010 5:05 PM, Rachel McConnell wrote:
This comment isn't helpful I know but I am very curious about this.
The code you quoted is a tag library call using the EL. How is that
not part of the UI? Are you writing controllers in JSP somehow?
Rachel
On Fri, May 7, 2010 at 2:47 PM, Aaron Freemanaaron.free...@layerz.com
wrote:
This isn't in the UI layer. This is in a controller. At any rate there is
a simple work around, but this sure doesn't seem like it should be
generating an error. If a property doesn't exist on an object it sure seems
like the test for empty=true should work, and not throw a runtime error.
At any rate there are easy workarounds in this case but workarounds make the
code uglier.
Aaron
On 5/7/2010 3:57 PM, Jon Stevens wrote:
I don't know if there is a way and it isn't something I'd depend on in the
UI layer. Think of [class] like you'd think of an interface. You really
should only put implementations of interfaces into the context. Otherwise,
I'd consider putting a Map in there for the effect you want.
jon
On Fri, May 7, 2010 at 1:43 PM, Aaron Freemanaaron.free...@layerz.com
wrote:
Bummer, what's the proper way to test if a property exists then, since
${!empty [class].[property]} isn't the correct way?
Thanks,
Aaron
On 5/7/2010 3:07 PM, Jon Stevens wrote:
That is what JBoss does, so I'd say that Caucho fixed a bug.
jon
On Fri, May 7, 2010 at 12:59 PM, Aaron Freemanaaron.free...@layerz.com
wrote:
We are system testing Resin 4.0.6 with our old code base and found a
curiosity. The following code used to work, regardless of what type
receipt is:
c:if test=${!empty receipt.details}
Under Resin 3.0.x if receipt was a HashMap and had a details property
then it would return true. If it was a HashMap and did not have a
details property, it would correctly return false. And (most
importantly), if receipt was _any_ other class, including built in java
classes, it would just return false. With Resin 4.0.6 it now throws an
error:
'details' is an unknown bean property of 'java.math.BigDecimal'
That's not the expected behavior is it?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question about Resin 4.0.6
You might want to take a look at a project I created several years ago
that works pretty much like this. I still find it occasionally
useful, although most of my frontends are GWT and javascript these
days:
http://tagonist.tigris.org/
It lets you use JSP files as controllers but keeps your Java code nice
and tidy. Super-simple.
Jeff
On Fri, May 7, 2010 at 6:06 PM, Aaron Freeman aaron.free...@layerz.com wrote:
Yes, that's exactly right. In several instances we have many
controllers that are written in JSP (pure JSTL code), that c:import
our models (also in this case JSPs) and also c:import our views.
Works great!
The upside to it is: a) easier to code -- people with limited Java
expertise can modify the controllers if they are not too complex (and
rarely are), and b) you can change your controllers on the fly without
having to restart Resin (primary reason we do this).
Aaron
On 5/7/2010 5:05 PM, Rachel McConnell wrote:
This comment isn't helpful I know but I am very curious about this.
The code you quoted is a tag library call using the EL. How is that
not part of the UI? Are you writing controllers in JSP somehow?
Rachel
On Fri, May 7, 2010 at 2:47 PM, Aaron Freemanaaron.free...@layerz.com
wrote:
This isn't in the UI layer. This is in a controller. At any rate there is
a simple work around, but this sure doesn't seem like it should be
generating an error. If a property doesn't exist on an object it sure seems
like the test for empty=true should work, and not throw a runtime error.
At any rate there are easy workarounds in this case but workarounds make the
code uglier.
Aaron
On 5/7/2010 3:57 PM, Jon Stevens wrote:
I don't know if there is a way and it isn't something I'd depend on in the
UI layer. Think of [class] like you'd think of an interface. You really
should only put implementations of interfaces into the context. Otherwise,
I'd consider putting a Map in there for the effect you want.
jon
On Fri, May 7, 2010 at 1:43 PM, Aaron Freemanaaron.free...@layerz.com
wrote:
Bummer, what's the proper way to test if a property exists then, since
${!empty [class].[property]} isn't the correct way?
Thanks,
Aaron
On 5/7/2010 3:07 PM, Jon Stevens wrote:
That is what JBoss does, so I'd say that Caucho fixed a bug.
jon
On Fri, May 7, 2010 at 12:59 PM, Aaron Freemanaaron.free...@layerz.com
wrote:
We are system testing Resin 4.0.6 with our old code base and found a
curiosity. The following code used to work, regardless of what type
receipt is:
c:if test=${!empty receipt.details}
Under Resin 3.0.x if receipt was a HashMap and had a details property
then it would return true. If it was a HashMap and did not have a
details property, it would correctly return false. And (most
importantly), if receipt was _any_ other class, including built in java
classes, it would just return false. With Resin 4.0.6 it now throws an
error:
'details' is an unknown bean property of 'java.math.BigDecimal'
That's not the expected behavior is it?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question about Resin 4.0.6
On 5/7/2010 5:39 PM, Jeff Schnitzer wrote: I doublechecked the spec and the current Resin behavior is the proper behavior. I don't think this behavior has changed in the spec, so the old behavior was a bug. You can't use the empty operator to test for the existence of fields (or methods). Okidoke. As to the rationale for the spec... it does make some amount of sense, helping to reduce one very common type of bug (I'm getting properties of a ThingA and the object turns out to be a ThingB). I'm sure all the arguments for static typing vs duck typing apply here. That's a bummer. I preferred the old behavior as it's closer to JavaScript associative arrays, which are nice and flexible. But mainly because we were relying on that behavior. :) Note: There is nothing special about the empty operator; expressions are resolved as normal and then the result is tested for null or empty collection. If expression evaluation ever tries to access a field or method that doesn't exist on an object, the EL resolver throws PropertyNotFoundException or MethodNotFoundException. Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
