How to validate beans.xml using a local XSD? - java

In my application, I have some beans.xml files (for eeach module). each of these files contains required XSD declarations :
<beans xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:weld="http://jboss.org/schema/weld/beans"
xsi:schemaLocation="
http://java.sun.com/xml/ns/javaee http://docs.jboss.org/cdi/beans_1_0.xsd
http://jboss.org/schema/weld/beans http://jboss.org/schema/weld/beans_1_1.xsd">
Yesterday, due to some JBoss.org outage, schema files were unavailable, and as a consequence my beans.xml couldn't correctly validate.
It didn't prevent the project from validating, but slowed down project build (due to weld usage in tests, mainly).
So, what is a the solution, when using Weld 1.1.5 as CDI implementation, to not validate beans.xml during compilation, or to use a local XSD file (and if so, how to declare it, and where to put it in a maven project) ?

Just spoke with Pete Muir. He said its a bug. Would you mind creating a JIRA ticket please?

Related

TomEE Share Persistence among different applications

Supposing I have a jar with the persistence.xml configuration and the jpa entities.
I would like to have the same persistence unit shared among different applications.
For example deploy a war application and have the same persistence unit (that other applications use) injected.
#PersistenceContext(unitName="MySharedPersistence")
private EntityManager entityManager;
I can not consider packaging all the applications in an ear file since I want to have the other applications up and running while I reupload an application (the application reuploaded uses some remote ejbs from the already deployed applications and uses the same persistence unti as described above).
Are there any solutions to this problem?
Thank you in advance.
EDIT: Probably It is not recomended are there any appropriate tryouts with the same result?
You can place your Entity classes and your persistence.xml in a jar, and reuse this jar in all projects. As long as you also include a beans.xml file along with your persistence.xml, it should work just fine. You should then be able to inject the persistence context in any project that uses this jar file.
You need the beans.xml file for autodiscovery by the container. For reference, here's how a beans.xml file would look:
<?xml version="1.0" encoding="UTF-8"?>
<beans 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/beans_1_0.xsd">
</beans>

How to reference JSF managed beans which are provided in a JAR file?

I have a WAR file with the following structure:
The JSF managed bean BusinessObjectTypeListController is located in commons-web-1.0.jar in /WEB-INF/lib and referenced in BusinessObjectTypeListView.xhtml. When I run my web application and I call that view, I get the following error:
javax.servlet.ServletException: /view/common/businessObjectTypeListView.xhtml #34,94 listener="#{businessObjectTypeListController.selectData}": Target Unreachable, identifier 'businessObjectTypeListController' resolved to null
Why isn't the controller class found? It should be in the classpath, is it?
You need to have a JSF 2.0 compliant /META-INF/faces-config.xml file in the commons-web-1.0.jar file in order to get JSF to scan the JAR file for classes with JSF annotations like #ManagedBean and auto-register them.
<?xml version="1.0" encoding="UTF-8"?>
<faces-config
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-facesconfig_2_0.xsd"
version="2.0">
</faces-config>
JSF does namely not scan every class of every single JAR file in the classpath, that would have been too expensive. Only JARs with the above /META-INF/faces-config.xml file will be scanned.
You should also ensure that you do not have the metadata-complete="true" attribute in the <faces-config> declaration of webapp's own /WEB-INF/faces-config.xml file, otherwise JSF will assume that this faces config is complete and therefore won't auto-scan JAR files for annotations.
If none of those conditions are (or can be) met, then you need to manually register the bean as <managed-bean> in webapp's own /WEB-INF/faces-config.xml instead of relying on annotations.
See also chapter 11.4.2 of JSF 2.0 specification (emphasis mine).
11.4.2 Application Startup Behavior
...
This algorithm provides considerable flexibility for developers that are assembling the components of a JSF-based web
application. For example, an application might include one or more custom UIComponent implementations, along with
associated Renderers, so it can declare them in an application resource named “/WEB-INF/faces-config.xml”
with no need to programmatically register them with Application instance. In addition, the application might choose
to include a component library (packaged as a JAR file) that includes a “META-INF/faces-config.xml” resource.
The existence of this resource causes components, renderers, and other JSF implementation classes that are stored in this
library JAR file to be automatically registered, with no action required by the application.
I have same problem with CDI beans in my case.
I have common.jar project where i placed the CDI beans. (without beans.xml)
and
I have webapp.war that contains common.jar in it`s lib and beans.xml.
when i call a cdi bean from jsf, i get it is not reachable exception:/
project structure is created using maven :
- maven-archetype-quickstart for common.jar
- maven-archetype-webapp for webapp.war
I am using eclipse/juno en deploy to Glassfish 3.1.x.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Resolved:
For EJB and JAR packaging you should place the beans.xml in src/main/resources/META-INF/.
For WAR packaging you should place the beans.xml in src/main/webapp/WEB-INF/.
Remember that only .java files should be put in the src/main/java and src/test/java directories. Resources like .xml files should be in src/main/resources.
from topic:
CDI: beans.xml, where do I put you?
In my opinion the class BusinessObjectTypeListController is founded properly but does not instantiated.
How you create the instance of class on a view? If you use a BeanFactory review the config xml files

How do I resolve duplicate property errors in this j2ee schema?

I inherited a J2EE app written for deployment on Weblogic 10 and the developer primarily responsible for this application does not get this error when he opens the project in Eclipse.
I have the following very simple weblogic.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/920/weblogic-web-app.xsd">
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
</weblogic-web-app>
Eclipse generates a single XML validation problem for this file, which actually consists of a number of the same errors. The parent text of the XML problem is this:
The errors below were detected when validating the file "j2ee_1_4.xsd"
via the file "weblogic.xml". In most cases these errors can be
detected by validating "j2ee_1_4.xsd" directly. However it is
possible that errors will only occur when j2ee_1_4.xsd is validated in
the context of weblogic.xml.
And an example of the child errors. They all read this way:
sch-props.correct.2: A schema cannot contain two global components with the same name; this schema contains two occurrences of 'http://java.sun.com/xml/ns/j2ee,descriptionGroup'.
This is followed by a line number. There are about 50 of these errors, and only the quoted name at the end of the error changes.
I found the following bug in Sun's bug tracker which seemed to indicate a possible cause, but I'm not sure how I'd apply it to my project, if it's even relevant.
Impossible to create javax.xml.validation.Schema instance from "web-app_2_4.xsd"
I can't help but think that this is related to my Eclipse configuration, but at this point I'm at a loss.
Thanks for your time.
I ran into the same issue. I found an article online about needing to update to the latest schema so I looked through Oracle for latest schemas versions here: http://www.oracle.com/webfolder/technetwork/weblogic/weblogic-web-app/index.html
I modified my weblogic.xml file with the following:
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.7/weblogic-web-app.xsd">
...
</weblogic-web-app>
Regards,
Jose
You say this is written for WL 10.
My weblogic.xml begins as
<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app
http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
while I can see yours points to the Weblogic 9 namespace
xmlns="http://www.bea.com/ns/weblogic/90"
Does changing this make a difference?

Resolution should not happen via injection container error

I have an EJB3 project to be deployed on JBoss 5.1.0 GA. I have Stateless EJBs being injected into other Stateless beans and Servlets.
I'm using the #EJB annotation without any parameters to inject the EJB beans, (i have a test project just to simulate the injection, which works).
When i try deploying i get the error below.
"Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: Resolution should not happen via injection container"
I have searched but can't seem to find/pinpoint the cause of the error.
Update: 1
Both the EJB jar and WAR are deployed in the same EAR. I'm using the JEE5 archtype, http://code.google.com/p/javaee5-maven-archetype/ to create both the main project and test. The default code generated by the archtype works, and there is no need to specify the JNDI name in the #EJB injection.
Update: 2
The full deployment stacktrace, http://pastebin.com/CknXie13
Here's an oft overlooked gotcha: Make sure that you use the name of the Local Interface and not the implementation when declaring the class type of the EJB in the servlet or web service. So, the mappedName in JBOSS will point to the jndi binding for the implementation while the class type in the declaration will point to the interface. For example:
#EJB(mappedName="Foo/EmployeeManagerBean/local")
EmployeeManagerLocal manager;
Gotcha #2: Make sure that you are compiling with Java 1.6 or higher. This can be tricky in Eclipse. You have to check three places in Project->Properties to make sure: Project Facets, compiler compliance settings, and the build path.
Use the mappedName attribute of #EJB annotation, while injecting into the servlet
The attribute should contain the jndi name of the ejb.
Please check your web.xml version. Version 2.4 or earlier does not support dependency injection.
Here is the sample excerpt of version="2.5"
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" 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-app_2_5.xsd">
Are you putting your servlet in .WAR file? Put your servlet in .WAR file and your bean in .JAR file. Create and ear file and then deploy it
Known Issue;
http://community.jboss.org/message/8196#8196
https://jira.jboss.org/browse/JBAS-6332

Eclipse: How to convert a web project into an AspectJ project and weave and run it using the AJDT plug in?

What I want to do:
I want to use the #Configured annotation with Spring. It requires AspectJ to be enabled. I thought that using the AJDT plugin for compile time weaving would solve this problem. Before installing the plug in the dependencies which were supposed to be injected into my #Configured object remained null.
What I have done:
Installed the AJDT: AspectJ Development Tools plug in for Eclipse 3.4.
Right clicked on my web project and converted it into a AspectJ project.
Enabled compile time weaving.
What doesn't work:
When I start the Tomcat 6 server now, I get an exception*.
Other information:
I haven't configured anything in the AspectJ Build and AspectJ Compiler parts of the project properties.
JDT Weaving under Preferences says weaving is enabled.
I still have Java build path and Java Compiler under project properties. And they look like I previously configured them (while the above two new entries are not configured).
The icon of my #Configured object file looks like any other file (i.e. no indication of any aspect or such, which I think there should be). The file name is MailNotification.java (and not .aj), but I guess it should still work as I'm using a Spring annotation for AspectJ?
I haven't found any tutorial or similar which teaches: How to turn a Spring web application project into an AspectJ project and weave aspects into the files using the AJDT plugin, all within Eclipse 3.4. If there is anything like that out there I would be very interested in knowing about it.
What I would like to know:
Where to go from here? I just want to use the #Configured annotation of Spring. I'm also using #Transactional which I think also needs AspectJ.
If it is possible I would like to study AspectJ as little as possible as long as my needs are met. The subject seems interesting, but huge, all I want to do is use the above two mentioned Spring annotations.
*** Exception when Tomcat 6 is started:
Caused by: java.lang.IllegalStateException: ClassLoader [org.apache.catalina.loader.WebappClassLoader] does NOT provide an 'addTransformer(ClassFileTransformer)' method. Specify a custom LoadTimeWeaver or start your Java virtual machine with Spring's agent: -javaagent:spring-agent.jar
at org.springframework.context.weaving.DefaultContextLoadTimeWeaver.setBeanClassLoader(DefaultContextLoadTimeWeaver.java:82)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1322)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)
... 41 more
Have you added spring-aspects.jar to your aspect path for the project?
In the project properties, under 'AspectJ Build' -> 'Aspect Path' try adding spring-aspects.jar and clean building the project.
Sorry you might have already done this - but you didn't mention it.
It looks like the compile time weaving isn't working. Try adding the below lines to your applicationcontext.xml
<context:load-time-weaver />
<context:spring-configured/>
You'll probably want to add the following xsd to the xml file also
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd
For details see here:
http://static.springframework.org/spring/docs/2.5.x/reference/aop.html#aop-aj-ltw
You can use #Transactional without AspectJ. Your configuration file should contain something like following to make it work:
<?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:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:util="http://www.springframework.org/schema/util"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.5.xsd"
>
<tx:annotation-driven/>
tells spring to look for #transactional annotations when creating instances of configured beans. On finding such annotation, spring returns a dynamic proxy of the bean to the application code. This dynamic proxy ensures that whenever the annotated methods are called, spring is able to intercept it to provide intended transactional behavior. But the proxy-based AOP mandates that you code against interfaces and not concrete classes.

Categories