I want to be able to process generic AJAX requests that do more than just updating an existent component. How can I override the default PartialViewContext in the FacexContext?
It would appear you can specify your own PartialViewContextFactory in the faces-config file, like this:
<faces-config ...>
<application>
<factory>
<partial-view-context-factory>
com.yourcompany.jsfextention.MyPartialViewContextFactory
</partial-view-context-factory>
</factory>
...
</application>
...
</faces-config>
Related
We have a java application running on Webshere Application Server 8.5.5. There are two processes running in separate JVMs.
The application is doing some integration using an IBM Webshere Queue Manager and an Oracle 11c database. Both JMS and JDBC resources are configured to use XA transactions.
PROCESS 1:
Read a message from a MESSAGES queue and extract a message key used to identify related messages
Saves message to the database.
Check if the message key does not exist in a KEYS table and if it doesn't it inserts it
ONLY if the insert above happens it puts a message key into a KEYS queue
Commit the transaction
PROCESS 2:
Gets the message key from the KEYS queue
Deletes the message key from the KEYS table
Process all messages associated with received message key from MESSAGES table
What we observed is that in about 5 percent of the cases after getting the message key from the KEYS queue the PROCESS 2 sometimes cannot find the record to delete from the KEYS table just to become available milliseconds later. Trying to delete it multiple times fixed the problem but it became clear that even if PROCESS 1 is XA enabled it commits the JMS resource first and then the JDBC bringing for a very short period of time the data in an inconsistent state.
So here is my question:
Is there a way to force transaction manager to commit JDBC first and then the JMS?
We find this on IBM knowledge center and we try to configure commit-priority like this:
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-ext xmlns="http://websphere.ibm.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-ext_1_0.xsd"
version="1.0">
<session name="RepositoryInstanceFacade">
<resource-ref name="jms/MQConnectionFactory" commit-priority="1" isolation-level="TRANSACTION_READ_COMMITTED"/>
<resource-ref name="jdbc/MessageManagerDB" commit-priority="2" isolation-level="TRANSACTION_READ_COMMITTED"/>
</session>
</ejb-jar-ext>
However this did not solve our problem. I am sure we are not the only ones facing this problem but I just ran out of idea about what to try more. We ended up by putting the message key back in the KEYS queue and that solved the problem but it looks to me like a very unorthodox work around rather than a good solution for a critical 24 x 7 application.
Thank you in advance for your inputs.
UPDATE
I added this resource bindings file ibm-ejb-jar-bnd.xml file in the META-INF folder of my ejb application but still no luck. As part of the deployment I could see IBM manipulated that file and transformed it into an XMI file
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-bnd
xmlns="http://websphere.ibm.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee
http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd"
version="1.0">
<session name="RepositoryInstanceFacade">
<resource-ref name="jdbc/MessageManagerDB" binding-name="jdbc/MessageManagerDB"/>
</session>
</ejb-jar-bnd>
UPDATE 2
I ended up with below configuration in two JVMs each JVM running its own application:
application.xml:
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_6.xsd"
version="6">
...
<resource-ref>
<description>XA Message Manager Data Source</description>
<res-ref-name>java:app/env/jdbc/MessageManagerDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
</application>
ibm-aplication-bnd.xml:
<?xml version="1.0" encoding="UTF-8"?>
<application-bnd
xmlns="http://websphere.ibm.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee
http://websphere.ibm.com/xml/ns/javaee/ibm-application-bnd_1_0.xsd"
version="1.0">
<resource-ref name="java:app/env/jdbc/MessageManagerDB" binding-name="jdbc/MessageManagerDB"/>
</application-bnd>
ibm-ejb-jar-ext.xml:
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-ext xmlns="http://websphere.ibm.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-ext_1_0.xsd"
version="1.0">
<session name="RepositoryInstanceFacade">
<resource-ref name="java:app/env/jdbc/MessageManagerDB" isolation-level="TRANSACTION_READ_COMMITTED" commit-priority="2"/>
</session>
</ejb-jar-ext>
spring data source bean:
<jee:jndi-lookup id="messageManagerDB" jndi-name="java:app/env/jdbc/MessageManagerDB"/>
And run again my tests. I was very happy during the test run as no warning messages came in the logs. However giving the test was running for a few hours it was hard to manually check all the time. In the end there were still three warning messages showing that JMS message was still read from the queue before the database insert was available. Am I still missing something?
Note that I took out any setting for JMS connection factory as according with the IBM documentation it would stay set to zero so it would have a lower commit priority than JDBC.
UPDATE 3
As advised by the comment and by IBM support I ended up with the following settings below:
ejb-jar.xml:
<session name="RepositoryInstanceFacade">
...
<resource-ref>
<description>XA Message Manager Data Source</description>
<res-ref-name>jdbc/MessageManagerDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
</session>
ibm-ejb-jar-bnd.xml:
<resource-ref name="jdbc/MessageManagerDB" binding-name="jdbc/MessageManagerDB"/>
ibm-ejb-jar-ext.xml:
<session name="RepositoryInstanceFacade">
<resource-ref name="jdbc/MessageManagerDB" isolation-level="TRANSACTION_READ_COMMITTED" commit-priority="2"/>
</session>
spring data source bean:
<jee:jndi-lookup id="messageManagerDB" jndi-name="java:comp/env/jdbc/MessageManagerDB"/>
With these settings in place JMS is still committed first and the JDBC last so it is still not working as expected.
Per the question that I asked in the comments, the resource reference is not actually being used to look up the resource, which is why the commit-priority attribute isn't being honored. In the UPDATE section of the question, you've gotten closer by adding the resource reference binding for the JDBC resource (you'll also need an equivalent for the JMS resource). You will also need to define the resource references in an ejb-jar.xml deployment descriptor (or annotation equivalent if you prefer), and then to look up the resources from your application, you need to use the namespace for the resource reference, which by default is java:comp/env, so you will need to look up the resources as java:comp/env/jms/MQConnectionFactory and java:comp/env/jdbc/MessageManagerDB. If you need visibility outside of the component level, you could would need to define at another scope such as java:module/env or java:app/env which would mean updating the resource reference name to the corresponding value as well.
UPDATE: example of ejb deployment descriptor/bindings/extensions with java:app name
ejb-jar.xml:
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" version="3.0" metadata-complete="false">
<enterprise-beans>
<session>
<ejb-name>RepositoryInstanceFacade</ejb-name>
<resource-ref>
<description>XA Message Manager Data Source</description>
<res-ref-name>java:app/env/jdbc/MessageManagerDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
</session>
</enterprise-beans>
</ejb-jar>
ibm-ejb-jar-bnd.xml:
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd"
version="1.0">
<session name="RepositoryInstanceFacade">
<resource-ref name="java:app/env/jdbc/MessageManagerDB" binding-name="jdbc/MessageManagerDB"/>
</session>
</ejb-jar-bnd>
ibm-ejb-jar-ext.xml:
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-ext xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://websphere.ibm.com/xml/ns/javaee"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-ext_1_0.xsd"
version="1.0">
<session name="RepositoryInstanceFacade">
<resource-ref name="java:app/env/jdbc/MessageManagerDB" isolation-level="TRANSACTION_READ_COMMITTED" commit-priority="2"/>
</session>
</ejb-jar-ext>
Application code to look up the data source and verify that the isolation level from the extensions is being used:
DataSource ds = InitialContext.doLookup("java:app/env/jdbc/MessageManagerDB");
Connection con = ds.getConnection();
try {
int iso = con.getTransactionIsolation();
System.out.println("Isolation level is " + iso);
} finally {
con.close();
}
If the above code outputs 2 (the value of java.sql.Connection.TRANSACTION_READ_COMMITTED), rather than the default isolation level of 4, this demonstrates that the bindings/extensions are being applied.
If after this point, you still don't seeing the commit-priority being honored, then it's a transaction management bug and I recommend reporting it to IBM support.
After upgrading the JSF implementation in our project from Myfaces 1.1 to MyFaces 2.2.12, my IDE (IntelliJ) shows me errors for all navigation-rule and managed-bean entries in my faces-config.xml. I have changed the root element in that file from
<!DOCTYPE faces-config PUBLIC
"-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
"http://java.sun.com/dtd/web-facesconfig_1_0.dtd">
<faces-config>
to
<faces-config
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
version="2.2">
navigation-rule entries like the following used to work and didn't show any errors before the upgrade:
<navigation-rule>
<navigation-case>
<from-outcome>exampleOutcome</from-outcome>
<to-view-id>/newpages/view1.jsp</to-view-id>
</navigation-case>
</navigation-rule>
After the upgrade to JSF 2.2, the navigation-case element is error-marked with a red underline. When hovering the text with the mouse, I get the error message:
Invalid content was found starting with element 'navigation-case'. One of '{"http://xmlns.jcp.org/xml/ns/javaee":from-view-id}' is expected.
Does this mean the from-view-id has become obligatory with JSF 2.2?
managed-bean entries like
<managed-bean>
<managed-bean-name>ExampleBean</managed-bean-name>
<managed-bean-class>my.example.package.ExampleBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
produce the similar error message:
A field of identity constraint 'faces-config-managed-bean-name-uniqueness' matched element 'faces-config', but this element does not have a simple type.
I haven't found anything about structural changes like this becoming necessary with the upgrade to JSF 2.2. Interestingly, I didn't get this error with an intermediate change to JSF 2.1!
Could anyone point me in a direction that might help this problem?
Try this :
<?xml version="1.0" encoding="UTF-8"?>
<faces-config
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
version="2.2">
<navigation-rule>
<display-name>first_page.xhtml</display-name>
<from-view-id>/first_page.xhtml</from-view-id>
<navigation-case>
<to-view-id>/second_page.xhtml</to-view-id>
</navigation-case>
</navigation-rule>
I know i can disable for the server or application in the xsp.properties via:
xsp.client.validation=false
And at the control level via:
disableClientSideValidation="true"
Short of setting disableClientSideValidation for each control, is there any way to disable at the XPage level?
Please try the following:
<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
<xp:this.properties>
<xp:parameter name="xsp.client.validation" value="false" />
</xp:this.properties>
</xp:view>
Update: Somehow, after another round of adjustments and redeployment, localhost:8080/ping-1.0/ping started working. Configuration files are still as below. I wish I knew what I fixed without knowing it, but it is solved now.
I've been wrestling with this for a couple days, tried all sorts of solutions I've seen here and elsewhere, and nothing has worked. I have a Spring MVC controller deployed in Tomcat, but can't access it.
Tools:
Spring 3.2.0
Tomcat 7
Java 1.6
Spring controller:
#Controller
public class PingController {
#RequestMapping("/ping")
public String ping (Model model) throws Exception {
System.out.println("ping ping ping");
String s = (new Date()).toString();
model.addAttribute("message", s);
return "ping";
}
}
web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<servlet>
<servlet-name>ping</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class><init-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/ping-servlet.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>ping</servlet-name>
<url-pattern>/ping</url-pattern>
</servlet-mapping>
</web-app>
ping-servlet.xml:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:mvc="http://www.springframework.org/schema/mvc"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="
http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-3.0.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd">
<context:component-scan base-package="myclass.ping"/>
<mvc:annotation-driven />
</beans>
The WAR file is called ping-1.0.war. Deployment seems to go fine. I see a directory called ping-1.0 in $CATALINA_BASE/webapps and this in catalina.log:
INFO: Mapped "{[/ping],methods=[],params=[],headers=[],consumes=[],produces=[],custom=[]}" onto public java.lang.String myclass.ping.PingController.ping(org.springframework.ui.Model) throws java.lang.Exception
Tomcat is running on port 8080. I can access localhost:8080/manager for instance. But localhost:8080/ping returns a 404 message from Tomcat. I see nothing in the logs other than a record of a GET request. No errors at all. I've tried a lot of variations of request mapping, URL filter, etc. and just can't get this to work.
You don't have the context root on your URL and you actually need to have /ping/ping because both the dispatcher servlet and your ping controller are mapped to /ping. Try this:
http://localhost:8080/ping-1.0/ping/ping
#RequestMapping("/ping")
Means /ping relative to the URL the dispatcher servlet listens on.
<url-pattern>/ping</url-pattern>
Here comes the problem. This makes your dispatcher servlet listen to one URL and one URL only. And that is assumingly localhost:8080/ping-1.0/ping. But your controller method is relative to that, so it would be localhost:8080/ping-1.0/ping/ping, and the disptacher servlet does not react on that URL. You have to use a pattern:
<url-pattern>/ping/*</url-pattern>
Now the dispatcher servlet can listen on all URLs starting with localhost:8080/ping-1.0/ping.
One final note: Depending on your configuration it could be that you have to omit ping-1.0.
I think you've configured Spring incorrectly.
I'd expect the servlet to be Spring's dispatcher servlet, not your ping controller. That's what figures out where to route the request. You don't have a front controller servlet.
I could be thinking Spring 2.x and earlier. I'll admit that I'd be incorrect if Spring 3.x changed the need for the dispatcher. But that's the way my applications are set up.
I have use a .dtd to my applicationContext.xml, but now i want to use Spring's AOP based on annotation. I've been told to add a in my applicationContext.xml.
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
<aop:aspectj-autoproxy />
...
But something wrong happens. It seems that the file doesn't recognize the aop node, so i think i should import one more .dtd file, and i find this:
<!DOCTYPE aspectj PUBLIC
"-//AspectJ//DTD//EN" "http://www.eclipse.org/aspectj/dtd/aspectj.dtd">
but can i use both .dtd togeter? how?
thx
You don't have to use DOCTYPE here, better declare xml namespaces like this:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop.xsd">
<beans>
<aop:aspectj-autoproxy />
...
xmlns="http://www.springframework.org/schema/beans" means that beans will be root namespace (you don't have to use <beans:bean>) and aop will be accesible as desired.
The two DTDs you cite are not constructed in a way that allows them to be used together. In particular, the definition of beans in http://www.springframework.org/dtd/spring-beans.dtd is just
<!ELEMENT beans (
description?,
(import | alias | bean)*
)>
It does not provide for a child named aop:aspectj-autoproxy, and it doesn't provide any mechanism for later users like you to add new things to the content of beans.
DTDs can be built for extensibility and to support the integration of elements from multiple namespaces, though it requires a bit of forethought and planning. When extension points are not included, it's typically pretty hard or impossible to extend the DTD without just rewriting it.