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.
While evaluating issue 105720 I noticed that the appserver plugin passes simple file names to J2eeModule.getDeploymentConfigurationFile("sun-ejb-jar.xml" and "sun-cmp-mappings.xml"), unlike the JBoss plugin, which prefixes the file names with the path in the archive ("META-INF/jboss.xml"). This happens at least for the EJB project. I'm not sure which way is correct, but the Javadoc of the gDCF() method seems to imply that the latter. I will thus fix issue 105720 by stripping META-INF from the passed file names, so the result for "META-INF/jboss.xml" will be <project_dir>/src/conf/jboss.xml. Perhaps the appserver plugin should pass prefixed file names as well.
it looks like this is ambiguous, pcw made the switch from "META-INF/sun-X.xml" to "sun-X.xml". I would assume it was for a reason.
Hi Andre, I can see why you'd think that, based on the 6.0 docs, which I find quite interesting because I think they are completely wrong. J2eeModule.getDeploymentConfigurationFile() in 6.0 was supposed to be (IMO) exactly the same as the method in J2eeModuleProvider by the same name (see 5.5.1 - it was removed in 6.0). But somehow the documentation changed significantly (and thereby implied new and different behavior) and I do not know why. We need to ask Stepan what's up with this. I think it's wrong on two counts: 1) The documentation says (implies) it only works for standard descriptor files (J2eeModule would not know about anything else - only server plugins will know about server specific files). This is just plain wrong. 2) The documentation says to pass in a file name (yay!) but then gives "WEB-INF/web.xml" as an example (boo!) -- this is a change in behavior from the 5.5.1 and prior implementations in J2eeModuleProvider, which did not expect nor document any such required prefix. The file names passed in historically have been simple file names, no prefix of any kind (e.g. WEB-INF or META-INF). The reason is that the caller is passing in a file name of a descriptor or similarly related configuration file and is requesting a fully qualified path back of where that particular file belongs on disk (for that project type, that server, yadda yadda yadda). Since the implementing project type already encapsulates such knowledge as "WEB-INF", "META-INF", "src/conf", etc., the server plugin should not also be so burdened.
Oh great... forget all that. I have to research this again. Looks like the prior version may have required the WEB-INF/META-INF stuff after all, I misread a hash lookup. Let's resolve this in email between the required parties and then just make it work.
Today is apparently blond moment day... Plese disregard my disregard comment... I got J2eeModuleProvider.getDeploymentConfigurationFile(String fname) (which does not use the prefix argument) confused with J2eeModuleProvider.findDeploymentConfigurationFile(String fname) (which does use it). So my orginal large commentary above stands.
I agree that the documentation is quite confusing and should be fixed. The reason why the method attribute is a relative path and not a name of the file is consistency. Plugins specify their server specific configuration files as relative paths through the layer file. J2eeModule had also a method J2eeModule.getDeploymentDescriptor with a file attribute, which was a relative path to a standard descriptor e.g. WEB-INF/web.xml. Although the method has changed to J2eeModule.getMetadataModel(Class<T> type), the relative path constants remained in J2eeModule. BTW, since the new method is a replacement for the two getDeploymentConfigurationFile and findDeploymentConfigurationFile methods, I wouldn't really consider it as a significant change in behavior. Peter, provided that the javadoc was fixed to talk about a file relative path instead of a file name, would you still consider this as an issue?
1. At one level, I just want it to work, I want it documented (for the maintainers mostly), and I want no regressions. About every 3-6 months a maintainer changes an implementation in this area and my code breaks. If this is all I can get, I can live with it. 2. I'd really like it to be consistent. It doesn't have to be, but it's a pain to use it otherwise. Let me give you an example: This is a mapping of module types to the "correct value" to pass to J2eeModule.getDeploymentConfigurationFile() when I'm trying to lookup a reference to the standard descriptor back (to locate the DDProvider, if any). standardDDNameMap.put(J2eeModule.WAR, J2eeModule.WEB_XML); standardDDNameMap.put(J2eeModule.EJB, "ejb-jar.xml"); standardDDNameMap.put(J2eeModule.EAR, "application.xml"); standardDDNameMap.put(J2eeModule.CLIENT, "application-client.xml"); webserviceDDNameMap.put(J2eeModule.WAR, J2eeModule.WEBSERVICES_XML); webserviceDDNameMap.put(J2eeModule.EJB, "webservices.xml"); A few months ago, this table used only constants from J2eeModule, but on June 8th, I had to fix it because something changed upstream and my code broke. This is nuts, it should be consistent and it shouldn't silently break. I also really don't like the idea of if-else code to determine whether or not to pass a prefix (and what the prefix is) in order to determine if a particular sun-???.xml file is in the official configuration folder.
none of these TM values are valid at this point
Improved javadoc web-main a9d6cf199c19.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/a9d6cf199c19 User: Petr Hejl <phejl@netbeans.org> Log: #108197 Weird parameters to J2eeModule.getDeploymentConfigurationFile()