This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Hello, it seems that Netbeans 7.01 does not recognize JSF Composite Components inside jars. So no code completion but instead big red errors in every xhtml page. In Netbeans 7.0 this worked without problems. My Setup: I have an Maven EAR Application with multiple web projects. Some web projects are only used as library for others. I use the Maven WAR overlay feature to archive this. http://maven.apache.org/plugins/maven-war-plugin/overlays.html This works well, but Netbeans was not capable of recognizing the composite components anymore. However I found a ugly workaround for this issue that worked with Netbeans 7.0. I created a new Java Project. This project contains only a faces-config.xml and all available composite components. The Web Projects have this as a "provided" dependency.
(In reply to comment #0) > However I found a ugly workaround for this issue that worked with Netbeans 7.0. So it doesn't it work in 7.0 as you said at the beginning? Do you need the workaround in both 7.0 and 7.0.1. Would it be possible to make a sample project I can use to reproduce the issue?
(In reply to comment #1) > (In reply to comment #0) > > However I found a ugly workaround for this issue that worked with Netbeans 7.0. > So it doesn't it work in 7.0 as you said at the beginning? Do you need the > workaround in both 7.0 and 7.0.1. > > Would it be possible to make a sample project I can use to reproduce the issue? Hello, thanks for your fast reply with my workaround (packing all JSF components in an own jar) it worked with Netbeans 7.0, but not with Netbeans 7.01. Without the workaround, just using war overlay it didn't work at all. Netbeans (7.0 and 7.01.) seems not to recognize resources from war overlays at all. But the not working war overlay is not my point. This would be a nice feature, but the bug I'm trying to describe here is: - Create a maven web application - create JSF composite components - package the JSF composite components into an own jar - Add this jar as dependency to the web project Netbeans 7.0 will recognize the components correctly, Netbeans 7.01 shows an error: "The component library http://java.sun.com/jsf/composite/components doesn't contain such component"
The behavior may depend on several factors. 1) is there a facelets library descriptor in the jar file? 2) is it properly located/named? 3) are the composite components in proper location (/META-INF/resources/library_folder/*.xhtml) and possibly others. I've tried to follow your scenario and it works for me: 1) create a maven web project (MWP_ 2) create a java library project (JLP) 3) in the JLP create /META-INF/resources/mylib/foo.xhtml 4) put interface section to the file with some attribute/s 5) build the JLP 6) add a dependency to the MWP 7) create an xhtml file in the MWP 8) add xmlns:x="" attribute to the root tag 9) invoke completion inside => the proper namespace http://java.sun.com/jsf/composite/mylib is offered => complete it 10) type x: somewhere in the file => your component offered with its attributes All above I'm trying in last dev build, but I believe there is no difference in the related areas between dev and 701. Can you compare (or follow) the scenario I tried with yours and let me know whether it works or what is the difference to yours? Thanks
(In reply to comment #3) > The behavior may depend on several factors. > > 1) is there a facelets library descriptor in the jar file? > 2) is it properly located/named? > 3) are the composite components in proper location > (/META-INF/resources/library_folder/*.xhtml) > > and possibly others. > > I've tried to follow your scenario and it works for me: > > 1) create a maven web project (MWP_ > 2) create a java library project (JLP) > 3) in the JLP create /META-INF/resources/mylib/foo.xhtml > 4) put interface section to the file with some attribute/s > 5) build the JLP > 6) add a dependency to the MWP > 7) create an xhtml file in the MWP > 8) add xmlns:x="" attribute to the root tag > 9) invoke completion inside => the proper namespace > http://java.sun.com/jsf/composite/mylib is offered => complete it > 10) type x: somewhere in the file => your component offered with its attributes > > All above I'm trying in last dev build, but I believe there is no difference in > the related areas between dev and 701. > > Can you compare (or follow) the scenario I tried with yours and let me know > whether it works or what is the difference to yours? > > Thanks Hello, What is a JLP? How can I create that with maven? I can't find it in the maven project list. I used Java Application as type. However I think the jar is packaged correctly. I added an attachment to show you the structure. I can't show you the components itself, but they are directly inside the "components" folder. I include them in a JSF Page with: xmlns:foo="http://java.sun.com/jsf/composite/components" The faces-config.xml: <?xml version='1.0' encoding='UTF-8'?> <faces-config version="2.0" 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"> </faces-config>
Created attachment 109745 [details] package structure of my jar
> What is a JLP? How can I create that with maven? I can't find it in the maven > project list. I used Java Application as type. As I wrote: > > 2) create a java library project (JLP) _J_ava _L_ibrary _P_roject. But I think Java Application is fine as well. The resulting jar file matters. > > However I think the jar is packaged correctly. I added an attachment to show > you the structure. I can't show you the components itself, but they are > directly inside the "components" folder. According to the snapshot it looks fine. I assume there are some xhtml files in the components folder... If the jar file is properly added to the classpath it should work. Faces-config doesn't play any role here. I mentioned facelets library descriptor *.taglib.xml file. > > I include them in a JSF Page with: > xmlns:foo="http://java.sun.com/jsf/composite/components" That's correct for the jar file content. How do you add the jar file to the maven web project classpath? Can you put here the POM.xml? Does the application work well when deployed? Can you compare my steps with what you are doing? Does it differ? If so please elaborate how *exactly* I can reproduce it. I would appreciate if you pack your project (both java and maven web) and attach it here or send it to me via email if it is confidential. Thanks in advance.
(In reply to comment #6) > _J_ava _L_ibrary _P_roject. This type is not offered by the Netbeans wizard. > Faces-config doesn't play any role here. I mentioned facelets library > descriptor *.taglib.xml file. I didn't know that such a file is needed, so it is not packaged in the jar. How should this file look like? (I mean what should it contain) > Does the application work well when deployed? Yes it does. But in the final EAR, the composite components from the war overlay are used. The only purpose for this jar is that Netbeans offers code completion. (It is only added as a dependency with scope "provided") > Can you compare my steps with what you are doing? Does it differ? If so please > elaborate how *exactly* I can reproduce it. I would appreciate if you pack your > project (both java and maven web) and attach it here or send it to me via email Your steps are identically to mine. It is very strange that it works for you. I have this problem with the latest development build as well- Sorry I cannot send you the project, because it is a commercial project. I will try to setup a demo project to reproduce the error.
> > Faces-config doesn't play any role here. I mentioned facelets library > > descriptor *.taglib.xml file. > > I didn't know that such a file is needed, so it is not packaged in the jar. How > should this file look like? (I mean what should it contain) It is not needed, but there can be. It can contain some metadata related to the components and the library itself. I asked because it makes quite difference from the netbeans facelets support if the file is there or not. But you do not need it. > Sorry I cannot send you the project, because it is a commercial project. I will > try to setup a demo project to reproduce the error. Yes, please do it and attach it here. Thanks.
(In reply to comment #8) > > > Faces-config doesn't play any role here. I mentioned facelets library > > > descriptor *.taglib.xml file. > > > > I didn't know that such a file is needed, so it is not packaged in the jar. How > > should this file look like? (I mean what should it contain) > It is not needed, but there can be. It can contain some metadata related to the > components and the library itself. I asked because it makes quite difference > from the netbeans facelets support if the file is there or not. But you do not > need it. > > > > Sorry I cannot send you the project, because it is a commercial project. I will > > try to setup a demo project to reproduce the error. > > Yes, please do it and attach it here. Thanks. Hello, it took me a while but I was able to reproduce my problem. I will attach my project to this bug report
Created attachment 109817 [details] Broken JSF CC support
Reproducible. There's a dependency from one WAR file to another WAR file (which contains the CC). In a WAR file the CCs can be stored in the resources folder in the root of the war. This is quite different from the JAR archive where it needs to be in /META-INF/resource. Should be fixed. Workaround is to use JAR archive as the container of the components.
The reason why it doesn't work properly is that the dependent maven web project doesn't show up on the source classpath of the depending project. Java Maven project works well. I'm not sure if this is an intention or a bug though. Davide, do you have an idea? You spent some time with the projects...
(In reply to comment #12) > The reason why it doesn't work properly is that the dependent maven web project > doesn't show up on the source classpath of the depending project. Java Maven > project works well. I'm not sure if this is an intention or a bug though. I do not think it is intention nor bug - there is just no support for "war dependency". I've never heard about "overlays" before. If overlays are something what's commonly used then perhaps we should provide support for. So far I find it quite obscure - why not just use jar dependency?
Hello, I'm sorry but I think we're talking past each other. As I already explained I'm not complaining about the not available "war-overlay" support. As you can see in my sample project I'm not only using war overlay! I have also created a simple Java project that contains only the Composite Components. Please have a look at the "jsfLibrary" project. This simple jar is also packed into my application. With this jar I was able to get Code Completion in Netbeans 7.0. But this workaround stopped working with Netbeans 7.01. and this is what this bug is about. I will also create a feature request for a better war overlay support but please notice this is not what I'm talking about here. To summarize this again: - I use war overlay and! a normal jar with the components. - The only purpose of the jar is to get code completion for netbeans. - It worked with Netbeans 7.0 - It stoped working with Netbeans 7.01
Feature request created: http://netbeans.org/bugzilla/show_bug.cgi?id=200776 And just to let you know: The reason that we use war overlay instead of simple jar libraries is because of bug(s) in JBoss Weld (We use Glassfish with CDI) . We had several problems with the cdi beans in libraries that caused the strange class cast exceptions. After we used war overlay the problems were gone. Also Netbeans offers more support if you create JSF Components inside a web applications instead of a java project. Some of the code completion and wizard seems to be only available if you develop in a web application.
(In reply to comment #15) > Feature request created: > http://netbeans.org/bugzilla/show_bug.cgi?id=200776 Thanks for the enhancement, I believe adding at least the classpath support would help. As for the problem with the workaround: The composite components support doesn't work properly since the jsfLibrary maven project doesn't contain the .xhtml files in the source folders, but it adds them to the resulting jar file via build resource by copying them from the BaseProject project. There basically two "scanners" (indexers) which look for the composite components. One which operates over sources, one for binary archives. AFAIR the problem is that if there's a project which provides a jar artifact, the binary indexer is not used and the source indexer does its work. Since the jsfLibrary project doesn't contain the composite componens as sources the source indexer find nothing and hence the support doesn't work. Would it be a big problem for you to copy the components into the jsfLibrary as sources? (we are still talking about a workaround. I'd prefer to fix 200776).
Btw. CDI in GF 3.0 used to have lots of problems. GF 3.1 should be much better in that respect.
Hello again, first thanks for the clarification. At least I know why it is not working. But I'm still wondering why it worked with Netbeans 7.0 Yes I know that CDI and Glassfish 3.0 are buggy, but this bug occurred also with Glassfish 3.1. Currently we use Glassfish 3.1.1 maybe I should try again... >Would it be a big problem for you to copy the components into the jsfLibrary as >sources? (we are still talking about a workaround. I'd prefer to fix 200776). You mean copy them by hand in the source folder every time someone changes a component? Sounds exhausting ;-). Could this be done by maven somehow?
(In reply to comment #18) > Hello again, > > first thanks for the clarification. At least I know why it is not working. > But I'm still wondering why it worked with Netbeans 7.0 I'll try to investigate ... > You mean copy them by hand in the source folder every time someone changes a > component? Sounds exhausting ;-). ok. I thought it is a kind of library you use so they don't change often. In such case just use symbolic link to the folder.
(In reply to comment #19) > ok. I thought it is a kind of library you use so they don't change often. In > such case just use symbolic link to the folder. I'm not allowed to create symbolic links because apparently on Windows you need administration rights to do so. Windows is sooo funny... However I've found another workaround. I added this line to my "jsfLibrary" pom.xml: <scriptSourceDirectory>../BaseProject/src/main/webapp/resources/</scriptSourceDirectory> and it works without duplicating anything.
>However I've found another workaround. I added this line to my "jsfLibrary" pom.xml: ><scriptSourceDirectory>../BaseProject/src/main/webapp/resource /</scriptSourceDirectory> >and it works without duplicating anything. So I reckon this war-overlay issue can be considered as resolved then.
*** Bug 199905 has been marked as a duplicate of this bug. ***