I am running tests with CDI-unit runner and want some classes to be excluded (because they act on CDI events). I tried beans.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<scan>
<exclude name="com.mypackage.**"/>
</scan>
</beans>
but CDI-unit seems to be ignoring it. So what is the correct way to exclude the classes with CDI-unit?
You may provide an alternative of the class you want to exclude, so that the alternative test class is used instead. With CDI Unit you turn on your alternative with #ActivatedAlternatives on your tests, or globally with #ProducesAlternative on your test producer. See more here: http://jglue.org/cdi-unit-user-guide/#alternatives
AFAIK, CDI Unit does not directly support exclusion of beans. But in most cases using alternatives is sufficient.
Related
I have a very tricky problem when overriding JSF-renderers.
This is a part of my faces-config.xml:
<?xml version="1.0" encoding="UTF-8"?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xi="http://www.w3.org/2001/XInclude" 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/web-facesconfig_2_0.xsd"
version="2.0">
<render-kit>
<renderer>
<component-family>org.primefaces.component</component-family>
<renderer-type>org.primefaces.component.MenubarRenderer</renderer-type>
<renderer-class>de.mycompany.web.MenuRenderer</renderer-class>
</renderer>
</render-kit>
<factory>
<exception-handler-factory>de.mycompany.web.ValidationExceptionHandlerFactory</exception-handler-factory>
</factory>
</faces-config>
The structure of my web-project is following
webapp (building war), Dependencies to core and gui
core (building jar)
gui (building jar), Dependencies to core, containing xhtmls and #Named Beans, Dependency to com.sun.faces:jsf-impl Version 2.1.25
When I place the content of the faces-config.xml in
webapp/src/main/webapp/META-INF or
core/src/main/webapp/META-INF
both, the MenuRenderer and the ValidationExceptionHandlerFactory, are getting used. Yeah.
When I place the content of the faces-config in
gui/src/main/webapp/META-INF
the ValidationExceptionHandlerFactory is getting used, but not the MenuRenderer. WTF?
Also all other features (phase-listeners, system-event-listeners I use in my faces-config are working except ones in the render-kit-nodes.
What am I doing wrong?
You're trying to override a renderer supplied by another external library, not a standard renderer.
The loading order of faces-config.xml provided by external libraries is by default undefined. In your specific case, your library is apparently loaded before PrimeFaces library is loaded.
You can explicitly specify the loading order via <ordering> element in faces-config.xml. The name of the PrimeFaces library is primefaces. So, just add the below entry to your faces-config.xml. Make sure you supply your library a name too so that endusers can in turn reorder in their own faces-config.xml if necessary.
<name>yourlibrary</name>
<ordering>
<after>
<name>primefaces</name>
</after>
</ordering>
A real world example can be found in e.g. OptimusFaces which also extends PrimeFaces.
I'm studing by few days Spring Integration and in some example i've noticed the use of channel and int:channel.
What is the difference ?
In the same way, there are other keywords: someone start with int: and other (with the same name) are not.
It just depends on how you configure the namespaces at the top of the XML file, and specifically the default xmlns. In the first case, the integration schema is the default, in the second, something else is, usually beans...
<beans:beans xmlns="http://www.springframework.org/schema/integration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:beans="http://www.springframework.org/schema/beans"
...
In this case, integration is the default xmlns and you would use
<channel ...
and
<beans:bean ...
here...
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:int="http://www.springframework.org/schema/integration"
...
beans is the default xmlns and you would use
<int:channel...
and
<bean ....
So, it's simply a matter of personal choice.
I don't know if this has a solution or is an IDE enhancement, but, when I'm using primefaces components in Netbeans, the autocomplete suggest the taglib p:..., no matter the id is http://primefaces.org/ui (should suggest pou), but if you're using primefaces extensions instead give pe as the showcase, gives poue.
So, now, I created a custom tag lib with id http://zeitek.net/ui, but as extensions is suggested znu, I know I can change it manually, but since is a collaborative project, I would like to use ztk as the predefined prefix to keep the standard in the code, is there anyway to achieve this with a JSF parameter or Netbeans configuration?
Well, if someone need this, i was missing this:
You need to create a tag-lib like normal and add this param:
<facelet-taglib
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/web-facelettaglibrary_2_0.xsd"
version="2.0"
id="zinf">
<namespace>http://zeitek.net/infraction/jsf/ui</namespace>
<composite-library-name>zinf</composite-library-name>
The last part is the important one: < composite-library-name>zinf< /composite-library-name>
It is not so much a question, more of a note.
With Glassfish4, in a JEE7 application I tried to use the flow scope using programmatic flow definition (java class annotated with #Produces #FlowDefinition).
I navigated to the start page of the flow with a h:commandButton (just as it is done in the JEE7 tutorial example https://svn.java.net/svn/javaeetutorial~svn/trunk/examples/web/jsf/checkout-module.
When I pressed the button it stayed on the same page, where the button was, instead of going to the flow's start page.
After many hours of suffering, I realized that the problem is in the beans.xml, in my beans.xml I had this:
bean-discovery-mode="annotated"
which is the recommended setting according to the documentation (http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/beans_1_1.xsd).
When I changed this to
bean-discovery-mode="all"
it started to work.
Somehow CDI does not recognize the flow definition as an annotated class. I tried to make it a #Named class, or a #ApplicationScoped class, but non of these helped.
I don't know if it is the intended behavior, or a bug.
Hope it saves a few ours to someone.
This is related to how CDI detects bean archives. When bean-discovery-mode="annotated", only classes annotated with bean defining annotations are picked up by CDI; note that #Named and #FlowScoped aren't on that list.
Because of this, as you've documented here, using Flow annotations requires bean-discovery-mode="all" to be set.
There's a spec issue open to discuss if this is a desired behavior.
Thank you!
Of course you can always fallback to using an XML declaration for your view. Such as creating a file example/example-flow.xml with contents such as
<?xml version='1.0' encoding='UTF-8'?>
<faces-config version="2.2"
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">
<flow-definition id="example">
<flow-return id="actionId" >
<from-outcome>#{somebean.returnValue}</from-outcome>
</flow-return>
</flow-definition>
</faces-config>
I have three different JAX-WS services which use the same classes on the server (e.g. ServiceA, ServiceB, and ServiceC, all of which use MyCommonClass as a parameter). Another module we are developing is using wsimport to create a client for these services, however the problem is that wsimport creates separate instances of MyCommonClass for each service:
com.company.servicea.endpoint.MyCommonClass
com.company.serviceb.endpoint.MyCommonClass
etc.
I know that I could use the wsimport -p option to specify a common package for each endpoint, however I'd like to keep most of the classes in separate packages, but just to share certain common ones. From what I have read it sounds like a JAXB bindings file(s) might be able to help, but I haven't yet figured out the exact syntax to achieve the desired result. I think I'll need a separate bindings file for each service (as I call wsimport once for each one), which looks something like this:
<?xml version="1.0" encoding="UTF-8"?>
<bindings xmlns="http://java.sun.com/xml/ns/jaxb" version="2.1" xmlns:tns="http://endpoint.servicea.company.com/">
<bindings node="//xsd:complexType[#name='myCommonClass']">
<class name="com.company.model.MyCommonClass"/>
</bindings>
</bindings>
Am I on the right track? Or do you have any alternative solutions to the problem?
Define your common classes in an xsd and import it in to the service WSDL's.
Then use the schema customization to generate definitions in this schema in to a separate package like "com.company.model"
<jxb:bindings
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
version="1.0">
<jxb:bindings schemaLocation="model.xsd" node="/xsd:schema">
<jxb:schemaBindings>
<jxb:package name="com.company.model"/>
</jxb:schemaBindings>
</jxb:bindings>
...
ref: http://jax-ws.java.net/jax-ws-21-ea1/docs/customizations.html#2.6_Class_Customization