I replaced all of my JNDI lookups with JNDI.lookup() method because it seemed convenient, dealt with dynamic return types, etc. All was great...but now I just noticed that the checked exceptions that I had to catch before are no longer there.
I assumed this was because it would have just returned null if the JNDI variable didn't exist but it doesn't. It now just throws an unchecked exception.
Any idea why? Is there a way of just returning null for non-existant variables instead?
I created a bug for this on the omnifaces website: https://github.com/omnifaces/omnifaces/issues/141
Not sure if this is intended behavior or not.
Is there a way of just returning null for non-existant variables instead?
It does that for NameNotFoundException. The problem was here not in OmniFaces, but in the environment, which was GlassFish 4.1 in your specific case. It unexpectedly wrapped the NameNotFoundException in another NamingException, hereby causing the underlying NameNotFoundException to slip through and bypass the return null condition.
This has been fixed with help of Exceptions#is() utility method as per this comment. It will be available in OmniFaces 2.2.
Related
I am facing an odd problem with Freemarker and the classloader that I did not use to have on 6.2.
Basically, there is a minor logic on the top of the template that uses Oauth. This use to work fine and I can't see a problem with it. I tried placing a variation of the Scribe everywhere I could, and even deleting the one that comes inside the ROOT.
What is odd is that the code successfully calls some methods before the exception is thrown, I guess then it is not a classloader problem but an issue with the unwrap operation. Did something change with regards to that functionality?
Code:
${callbackParameters.add(TrueNTHOAuthConstants.REDIRECT, portalUtil.getCurrentCompleteURL(request))}
<#assign trueNTHConnectLoginURL = trueNTHConnect.getAuthorizationUrl(companyId,1, callbackParameters) /> (Exception at this line)
FreeMarker template error:
No compatible overloaded variation was found; can't convert (unwrap) the 3rd argument to the desired Java type.
The FTL type of the argument values were: number (wrapper: f.t.SimpleNumber), number (wrapper: f.t.SimpleNumber), extended_hash+string (org.scribe.model.ParameterList wrapped into f.e.b.StringModel).
**The matching overload was searched among these members**:
com.sun.proxy.$Proxy799.getAuthorizationUrl(long),
com.sun.proxy.$Proxy799.getAuthorizationUrl(long, int, org.scribe.model.ParameterList, org.scribe.model.ParameterList),
com.sun.proxy.$Proxy799.getAuthorizationUrl(long, int, org.scribe.model.ParameterList)
I have just mentioned the classloader as I had to deal with several ClassNotFoundException or class definition not found to get to this point. This was somehow expected (unpredictable behavior) due to the library replication..
It's possible that you have two different classes loaded with org.scribe.model.ParameterList name. So trueNTHConnect uses another version of the problematic class than the methods called before it. The JVM will see them as totally different incompatible classes, hence there's no matching overload.
There's a sure way to find it out: debug or modify FreeMarker at the places where the class names are printed so that it prints the identity hash of the Class objects too.
I'm trying to establish a bidirectional data binding as follows:
<h:outputText value="#{cc.getAspect('meta').metaInfo.previousValue}" />
But I'm getting the following Exception, only when writing back though (the value is initially displayed just fine upon loading the page):
Caused by: javax.el.PropertyNotFoundException: /resources/meta.xhtml #23,124
value="#{cc.getAspect('meta').metaInfo.previousValue}":
The class 'org.foo.client.jsf.UIComponent' does not have the property 'getAspect'.
Now I'm wondering:
1) The getAspect method is definitely there (double checked, also it works upon read after all). By "property" does JSF denote a "field" and is actually implicitly trying to access setgetAspect or somthing? If so, why?
2) Why would it even try to write, that is to access a setter, on the getAspect in the first place?? The only value that is or should be written is previousValue, just located down the object path cc.getAspect('meta').metaInfo.previousValue which only reads the meta aspect via getAspect.
Any ideas greatly appreciated, thanks
EDIT: Environment: JBoss EAP 6.1.0.GA, JSF Implementation: Mojarra 2.1.19
I have created a simple bean using this example from Per
http://per.lausten.dk/blog/2012/02/creating-your-first-managed-bean-for-xpages.html
And I can access the bean using
helloWorld.setSomeVariable("test") and
get the value using helloWorld.getSomeVariable()
But when I try it using EL language it doesn't work
helloWorld.SomeVariable
I get an error that SomeVariable doesn't exists in helloWorld
I'm probably doing some simple error, but I can't see what.
I believe the problem is that EL is likely case-sensitive the bean-style name of the property is "someVariable". Beans assume that you're using camel-case for the method names, so EL downcases the first letter after "set" and "get" for their translation.
EL seems to be case sensitive in my regards and your property is defined as someVariable and not SomeVariable. have you tried helloWorld.someVariable.
I'm generating a jaxws client based on webservice. Jaxb will generate booleans using the java.lang.Boolean instead of the primitive type. In addition to this, it will generate the is() naming convention for beans.
However if I try to link the boolean (e.g. isOptional()) to a checkbox, it will throw the following exception:
value="#{property.optional}": Property 'optional' not readable on type java.lang.Boolean
My google skills have informed me that jsf works fine with:
boolean isOptional()
boolean getOptional()
Boolean getOptional()
But not with
Boolean isOptional()
However it is not feasible to update the beans manually due to the size and amount of the webservices, so is there any way to make jsf use the java.lang.Boolean isOptional() properly? Or can I somehow define a property in the jaxb bindings file at generation time which magically generates "getOptional()"?
On a sidenote, the following does work:
<h:selectBooleanCheckbox value="#{property.isOptional()}"/>
However I can't actually update the value presumably because it can't find the setter.
EDIT: I'm running the latest jdk 7, the output of "java -version":
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) Client VM (build 23.1-b03, mixed mode, sharing)
The output of "wsimport -version":
JAX-WS RI 2.2.4-b01
Generated code:
public Boolean isOptional() {
return optional;
}
Jaxb will generate booleans using the java.lang.Boolean instead of the primitive type. In addition to this, it will generate the is() naming convention for beans.
Using the is getter prefix for java.lang.Boolean was a known major mistake of JAXB. It has been fixed in version 2.1.13 which was released April 2010 already. Keep your libraries up to date.
See also this blog article for some background.
The Great JAXB API Blunder
September 15, 2006
You've got to hand it to Sun for screwing this one up. It's one thing to write software that doesn't adhere to a specification when the documentation is as thick as a textbook. Take, for example, just about anything created by the W3C. However, it's really bad when it is your own spec that you can't follow, especially when it is the most well known part of it. That's right, Sun missed by a mile on their own spec when they created the JAXB 2.0 API. The JAXB 2.0 compiler (XJC) incorrectly uses the prefix "is" rather than "get" when generating the getter method for a java.lang.Boolean property. While the JavaBean spec states that read methods for primitive booleans can use the alternate "is" prefix, this flexibility does not extend to its boolean wrapper counterpart.
8.3.2 Boolean Properties
In addition, for boolean properties, we allow a getter method to match the pattern:
public boolean is();
This "is" method may be provided instead of a "get" method, or it may be provided in addition to a "get" method. In either case, if the "is" method is present for a boolean property then we will use the "is" method to read the property value.
An example boolean property might be:
public boolean isMarsupial();
public void setMarsupial(boolean m);
Given that JAXB is a code generation framework, and the idea behind code generation frameworks is that the code is to be used "as is" and not modified thereafter, this is a pretty big "oops". While this issue has been reported, the response from Sun is "sorry, its too late".
This behavior is governed by the spec, and unfortunately it's just too late for the spec to change now.
In terms of the user experience, thanks to auto-boxing, I don't think this will be a real issue for people. Is the problem that you are using Introspector and it's missing the property?
Too late? Not a real issue? It's BROKEN. FIX IT! I also don't like the naive statement that it probably won't affect frameworks. Um, yes it will, considering other projects did happen to adhere to the spec (hibernate, spring, myfaces, etc.)
UPDATE: Stevo Slavic informed me that this has been fixed in JAXB 2.1.13. See JAXB-131 for details. Yeah!
JSF/EL is not at fault here. It's doing its job properly conform the JavaBeans spec.
I'm not sure why the latest and greatest JAXB version still generates the wrong method but I finally fixed it by adding "-B-enableIntrospection" (as per http://jaxb.java.net/2.2.4/docs/xjc.html) to the wsimport call. This results in:
public Boolean getOptional() {
return optional;
}
I am in Mongo-C# environment and we have been coding against Mongo for a while using Mongo 1.3.x DLL. Recently, I updated it to be 1.4.2 and everything else was fine until I faced a problem where I noticed that while previous version of Mongo DLL was treating
update.SetWrapped(property.Name, value);
all file when value was null but the recent version does not like it and it throws nullreference exception.
Problem here is that I would like it to be able to accept Null values. has anybody faced this problem before? If yes, how did you handle that?
There was a breaking change when this was introduced. You need to use BsonNull.Value for this. So, your code would look like this:
update.SetWrapped(property.Name, BsonValue.Create(value) ?? BsonNull.Value);
I believe you should have been able to pass C# null to Update.SetWrapped<T> because T is a POCO and not a BsonValue and the serializer for T would decide how to serialize C# null.
I've created a JIRA ticket for this:
https://jira.mongodb.org/browse/CSHARP-486
Note that while C# driver versions earlier than 1.4 did not throw a NullReferenceException, they also did not update the property to BSON null as you might have expected (passing C# null to SetWrapped turned the SetWrapped into a no-op in earlier versions).
The basic rules for C# null handling are clear:
C# null is not a valid BsonValue, use BsonNull.Value instead
C# null is valid for POCOs, and will probably be serialized as a BSON null (although technically a serializer for a POCO could choose a different representation)