- This topic has 5 replies, 3 voices, and was last updated 19 years, 10 months ago by
.
-
Posts
-
Hi,
We’ve been using MyEclipse to develop a WebLogic Portal Server application, and we recently ran in to an annoyance with this pairing. We’ve been using MyEclipse 3.7.1, Eclipse RC1 and Windows XP.
Basically, our problem was this: Portal uses a special configuration file in the META-INF directory of the Enterprise Application Project. (The file is called META-INF/application-config.xml).
After a lot of poking and prodding, we found a good development configuration for MyEclipse and Portal (and boy is that a complicated CLASSPATH!). So long as we deployed our application as an exploded archive, everything was great. There were a coupl’a situations where we wanted to use a .ear instead, and in those cases, Portal would spit and sputter and tell us that it couldn’t find the application-config.xml file.
What we eventually concluded was that when MyEclipse created the .ear file, it seemed to use a lower-case path name (meta-inf), rather than the upper case path name (META-INF). When we’d unzip it (using, say, WinZip), we’d end up with an uppercase directory. We could also repackage it with WinZip (and end up with an uppercase path).
We don’t hafta use a .ear very often, and we can build it using Ant or some other mechanism, but I thought I’d report this just in case you guys felt you might want to revise the way that works.
(Obviously, it’d also be nice if Portal wasn’t quite as finicky about the case-sensitivity).
BCing you
bcholmes,
What happened if you did a jar -x fileName.ear to your EAR file? Was the META-INF dir capitalized? Also why did you think that the meta-inf dir was lower cased when MyEclipse created it if you were able to get a capatalized dir when you unzipped it with WinZip? I’m not totally clear on the systematic testing of this (but I agree, this is a huge problem if MyEclipse is doing this)@support-rkalla wrote:
What happened if you did a jar -x fileName.ear to your EAR file? Was the META-INF dir capitalized?
Hurm. I may have to back off on some of the details of my assertion. WinZip is a bit bizarre about displaying all-uppercase directories — there’s a configuration that you have to set in order for it to properly display all upper-case class paths. Unless that is turned on, the path appears in lower-case.
When I issue a jar -tf fileName.ear, the path appears in the correct case.
At this point, I think the case-sensitivity is a red herring, but because we *believed* that that was the problem, we tried recreating the .ear via other means, which ultimately bypassed the problem.
What I *still* believe is that an .ear file generated by the MyEclipse deploy utility and an .ear file generated via other means (the two we’ve tried are Ant and WinZip) have some difference. When Portal reads the .ear generated by MyEclipse, it does not correctly find the META-INF/application-config.xml file (although other META-INF files, such as application.xml, are found correctly). When I use Ant or WinZip, I get a valid .ear that Portal can read.
I also still believe that Portal handles the search for application-config.xml differently than it handles other META-INF/ files (because, as I said, it correctly reads our application.xml).
I’ve tried digging my nose into the Ant source code looking for some clue about why this might be, but haven’t found anything (partially because I obviously can’t compare this to the MyEclipse code or look inside the Portal code).
BC
BC,
Thank you for the digging this is very strange… let me send this into the devs to see if they have anything to say about the compression code.What I *still* believe is that an .ear file generated by the MyEclipse deploy utility and an .ear file generated via other means (the two we’ve tried are Ant and WinZip) have some difference.
It could be caused by a difference in the version of the JDK running Eclipse. JDK 1.3.1 had a much different set of zip libraries than 1.4.0. What version of the JDK are you using to launch Eclipse (see Help > About Eclipse Platform > Configuration Details > eclipse.vm). If it’s not at least 1.4.1, please try starting Eclipse with the additional argument: -vm <path-to-javaw.exe>
@support-scott wrote:
It could be caused by a difference in the version of the JDK running Eclipse. JDK 1.3.1 had a much different set of zip libraries than 1.4.0. What version of the JDK are you using to launch Eclipse (see Help > About Eclipse Platform > Configuration Details > eclipse.vm).
We’re using JDK 1.4.2.04, so JDK version doesn’t seem like the culprit. But thanks for the suggestion.
Thanks,
BC
