Is seems that the credentialStore property is not being picked up when using the SBT. We have this property:
<managed-property>
<property-name>credentialStore</property-name>
<value>CredStoreCloudant</value>
</managed-property>
There is no change when I change the value to any odd name, while this name is clearly defined in the managed-beans.xml, like this :
<managed-bean>
<managed-bean-name>CredStoreCloudant</managed-bean-name>
<managed-bean-class>com.eoffice.sbt.credentialstore.CloudantCredentialStore</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
</managed-bean>
The managed-beans.xml is being used, when we change the property clientID , we do get the 401 error:
oauth_invalid_clientid
Which is expected behaviour.
The OAuth dance is performed nicely, but our code does not execute. It appears to be using the MemoryStore.
Related
We are upgrading from jsf 1.2 to jsf 2.
We are using apache myfaces 2.1 and rich faces 4.3.
Below is the xhtml code prior to migration :
<h:inputText id="#{userSearch}" value="#{bean.input}"/>
<rich:suggestionbox for="#{userSearch}" var="rslt" suggestionAction="#{bean.getSearchList}">
</rich:suggestionbox>
As per migration doc , replaced <rich:suggestionbox> with <rich:autocomplete>.
Following is the xhtml code :
<rich:autocomplete mode="ajax" autocompleteMethod="#{bean.getSearchList}" />
Below is the getSearchList method
public List<CustomObject> getSearchList(String searchNow) {
}
The <rich:autocomplete> component exists inside a custom component which is invoked like this :
<example:SearchUsr bean="#{someOtherObject.bean}"/>
The issue i am facing is , when an input is entered inside <rich:autocomplete> , ajax call happens but i am am getting below exception :
Target Unreachable, identifier 'bean' resolved to null.
I printed the value of bean (of bean.getSearchList ) inside xhtml and it is not null.
Am i missing anything while using <rich:autocomplete> ? Please help.
EDIT 1 :
When the autocompleteMethod is invoked like this : #{masterBean.object2.object3.getSearchList}, this issue is not observed where masterBean is the one defined in faces-config.xml with session scope. Also autocompleteMethod must accept String argument and not object.
So is it that we cannot invoke autocompleteMethod on an intermidiate object ? It has to be a bean defined in JSF ? It is strange , but I am observing the same behaviour.
EDIT 2 :
While trying to search for an answer , got this link which states the same issue : autocomplete method does not resolve bean if ui:included and only one parameter provided
It gives two options : define autocomplete method with 3 parameters , use a composite component, rather than a ui:inlcude.
As evident from EDIT 2 , the autocomplete method signature is changed as :
public List<CustomObject> getSearchList(FacesContext context, UIComponent uiComp,String searchNow) , and the issue is resolved.
I'm using JSF 2 and Sprig 3, and I want to migrate from using faces-config.xml to annotations.
old one : faces-config.xml :
<managed-bean>
<managed-bean-name>banqueBean</managed-bean-name>
<managed-bean-class>commun.BanqueBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>banqueService</property-name>
<value>#{banqueService}</value>
</managed-property>
<managed-property>
<property-name>banqueId</property-name>
<value>#{param.banqueId}</value>
</managed-property>
</managed-bean>
new one :
public class BanqueBean{
private Banque banque;
#ManagedProperty(name = "banqueService", value = "#{banqueService}")
private BanqueService banqueService;
#ManagedProperty(value = "#{param.banqueId}")
private String banqueId;
// setters for banqueService and banqueId
the value of banqueId is set using :
<f:param value="#{banque.id}" name="banqueId" />
the problem is that when using faces-config.xml the "System" calls the setter of banqueService before the setter of parameter banqueId so that I can use banqueService inside setBanqueId method.
when using annotations it calls the setter of banqueId before banqueService so that I get null as a value of it.
why it inverses the call of this tow methods?
You should not rely on managed property setter method invocation order at all. This is nowhere definied in the specification.
Just hook at that point when JSF is finished with setting of all managed properties. That's the #PostConstruct annotated method.
#PostConstruct
public void init() {
banque = banqueService.find(banqueId);
}
Stop doing business logic in setters, this is only necessary if you're still using legacy JSF 1.1 which didn't support #PostConstruct.
Unrelated to the concrete problem, are you aware of the new JSF2 <f:viewParam>? It might as well help you to get rid of this boilerplate in the bean and end up having only a Banque property and a reusable Converter.
See also:
ViewParam vs #ManagedProperty(value = "#{param.id}")
Background
A managed bean must have parameters configured through its web.xml file. The web.xml file defines context initialization parameters that are configured in JDeveloper (11.1.2.3) as follows:
The source for the definition of reporting.server.protocol follows:
<context-param>
<description>Defines the data transport mechanism to ret...</description>
<param-name>reporting.server.protocol</param-name>
<param-value>http</param-value>
</context-param>
The bean exposes public accessor methods for reportServerProtocol.
The source for the bean resembles:
#ManagedBean
#RequestScoped
public class OracleReportBean extends ReportBean {
#ManagedProperty("#{initParam['reporting.server.protocol']}")
private String reportServerProtocol = URLReportImpl.DEFAULT_PROTOCOL;
// ...
}
Problem
I would like to initialize the bean using context initialization parameters, rather than through FacesContext. In adfc-config.xml (note: not faces-confg.xml), some examples show references to initParam:
<managed-bean>
<managed-bean-name>reportBean</managed-bean-name>
<managed-bean-class>ca.corp.report.view.OracleReportBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>reportServerProtocol</property-name>
<property-class>java.lang.String</property-class>
<value>#{initParam['reporting.server.protocol']}</value>
</managed-property>
...
</managed-bean>
The key line being the value element #{initParam['reporting.server.protocol']}. However, JDeveloper shows the line as being incorrect. That is, the initParam context is not available within adfc-confing.xml.
The error is: "EL token initParam is unknown."
Question
Using an EL, how can the context initialization parameters be used to configure a managed bean, declaratively within ADFc?
Related Links
How to inject entire managed bean via #ManagedProperty annotation?
http://balusc.blogspot.ca/2011/09/communication-in-jsf-20.html
https://stackoverflow.com/tags/el/info
http://www.oracle.com/technetwork/developer-tools/adf/learnmore/43-remote-task-flow-169185.pdf
http://docs.oracle.com/cd/E25178_01/web.1111/b31974/taskflows_activities.htm
A bug in JDeveloper causes errors to be displayed:
However, even though the IDE displays an error, the code executes as expected.
In the ui layer you could try something like this :
<c:set target="${BeanName}" property="PropertyName" value="${true}"/>
When I access a JPA managed date value from JSF, it comes back with an javax.faces.component.UdateModelException saying
'Cannot convert 01.01.10 00:00 of type class java.util.Date to class org.apache.openjpa.util.java$util$Date$proxy
Using a JPA-managed date value (which means it is proxied) works fine when it is used directly from the EL likes this:
'<h:outputLabel value="MyDateValue" for="input"/>
'<h:inputText id="inputDate" value="#{bean.myDate}"/>
However, it causes trouble when trying to use it with composite components
and gives back the following converter exception and thus can't update the model...
The (simplified) JSF composite component inputDate.xhtml
<head>
<title>A date input field</title>
</head>
<composite:interface>
<composite:attribute name="dateValue"/>
</composite:interface>
<composite:implementation>
<h:outputLabel value="MyDateValue" for="input"/>
<h:inputText id="input" value="#{cc.attrs.dateValue}"/>
</composite:implementation>
Assumption:
It seems the proxy replacement in OpenJPA is handled differently when the value is being accessed from inside a composite. My guess is the EL-resolver handles calls to object values differently when it is passed to composites. Passing it to composites means it is first accessed within the composite, which is too late and the required replacement of the proxy is not accomplished (thus the converter exception)
So I tried to change the Expression Language for MyFaces, but it didn't work in Websphere, even though I changed the class loading to parent last and provided el-impl and el-api from glassfish in the lib folder and inserted the necessary context-param for MyFaces
How do you guys use JPA-managed dates (or other proxied entities) in composite components???
If you are using the sun EL implementation you might use the following ELResolver which works around this issue:
public class BugfixELResolver extends ELResolver {
//...
#Override
public Class<?> getType(ELContext anElContext, Object aBase, Object aProperty) {
if (aBase.getClass().getCanonicalName().equals("com.sun.faces.el.CompositeComponentAttributesELResolver.ExpressionEvalMap")){
Object tempProperty=((Map)aBase).get(aProperty);
if (tempProperty!=null&&tempProperty.getClass().getCanonicalName().equals("org.apache.openjpa.util.java.util.Date.proxy")) {
anElContext.setPropertyResolved(true);
return java.util.Date.class;
}
}
return null;
}
}
Add it to the faces-config this way:
<el-resolver>
xxx.BugfixELResolver
</el-resolver>
This workaround can also be used in environments where you can not change the EL implementation (like websphere etc.).
Here is the workaround. The problem seems to be WebSpheres' ExpressionLanguage Implementation or rather the order resolvers are executed. Registering the JBoss EL implementation works and resolves the date proxies before calling the composite component. I also tried the Glassfish EL, but it didn't work either...
Registering a alternative EL is quite strange: The setting in web.xml for MyFaces is
<context-param>
<param-name>org.apache.myfaces.EXPRESSION_FACTORY</param-name>
<param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
</context-param>
Additionally under WebContent/META-INF/services/ a file named javax.el.expressionFactory is needed with this single line org.jboss.el.ExpressionFactoryImpl. The class comes from jboss-el-2.0.2.CR1.jar
(sorry, couldn't find the link to a maven repo)
I will keep you updated once I find a better solution...
Maybe someone found a workaround for the following problem:
It seems as if AXIS 1.4 adds an <exceptionName> and a <hostname> element to each custom fault element. In the WSDL the fault is defined to only consist of a custom fault message systemMessage.
This is the answer returned from my service. Never mind about the error, it could be any error that is returned as a fault.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server.generalException</faultcode>
<faultstring/>
<detail>
<ns1:systemMessage xmlns:ns1="http://my.domain/workflow/engine/wsdl/types">
<message>nullcvc-datatype-valid.1.2.1: '2008-12-02T00:00:00' is not a valid value for 'date'.cvc-type.3.1.3</message>
<code>XML string is not valid</code>
<parameter/>
</ns1:systemMessage>
<ns2:exceptionName xmlns:ns2="http://xml.apache.org/axis/">com.domain.commons.ws.schema.SystemMessageType</ns2:exceptionName>
<ns3:hostname xmlns:ns4="http://xml.apache.org/axis/">my.host.com</ns3:hostname>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
It seems as if this is an error in Axis 1.4. Does anyone know a workaround for this behaviour?
There's a workaround for the problem:
In the AXIS generated fault class that extends from org.apache.axis.AxisFault alter the constructors as follows in order to suppress the elements (below is the fault class that is used for the fault returned in the question):
public SystemMessageType() {
// Suppress the two elements
this.removeHostname();
this.removeFaultDetail(org.apache.axis.Constants.QNAME_FAULTDETAIL_EXCEPTIONNAME);
}
public SystemMessageType(
java.lang.String message1,
java.lang.String code,
java.lang.String[] parameter) {
// Call the default constructor
this();
this.message1 = message1;
this.code = code;
this.parameter = parameter;
}
This workaround solves the problem. Nevertheless, whenever you regenerate your code for the SOAP web service you have to adapt the fault class.