shochan vanden

Greenhorn
+ Follow
since Feb 09, 2005
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by shochan vanden

Consider the market.
Java has a future, .Net has a future, just because, aside from creating new apps, both are constantly used to replace "old" systems.

Enterprise level development is strongly network related.
Don't choose a speciality/technology/language that is not natively web oriented if you don't want to end up in niche development.

As for choosing between java and .Net, it mostly depends on your state of mind. Do like to depend on One vendor only (comfortable: if something doesn't work blame it on MS), or do you like the freedom to choose between different vendors/opensource even if that sometimes makes things more complicated...

Speed and popularity are in my opinion irrelevant. How "fast" and how "popular" is Cobol? Customers are still using it though, see what I mean?

Who cares who wins or who loses: in that kind of "battle" with that kind of scale there is never a winner or a loser, there are only agreements.
Do you think IBM and Oracle would so massively invest $$$ for so many years now in Java if was so much a risk?

Tired of programming? Pass your J2EE architect certification and become a manager...
I see the future of developer as not being developers anymore... evolve to higher grounds, go for management.

---
"Furthermore it is my view that in the MS world they have to repeat things until either people start believing it, or die of boredom."
20 years ago
Doesn't sound ugly to me.

There are plenty cases where you want to override badly written code (Like Hibernate using the wrong context to load resources).

When you package your application (including your "a.jar" and "b.jar" files) either in a jar, war or ear file, add /META-INF/MANIFEST.MF (that is directory+file) to your jar, war or ear.

The /META-INF/MANIFEST.MF file has to contain the following:

Manifest-Version: 1.0
Class-Path: b.jar a.jar

Be careful with upper/lower case.
If "b.jar" is declared before "a.jar", the "b.jar" classes will override the "a.jar" classes with the same fully qualified name.

Cheers
[ February 09, 2005: Message edited by: shochan vanden ]
20 years ago

Originally posted by Michael Remijan:
I have to use a jar file which contains class files which are not packaged. None of the source files have the 'package xxx.yyy.zzz;' code in them. Now I'm developing an application that is packaged. When I try to compile I get standard "cannot resolve symbol" error even though the jar file is in the classpath. So how do I import a non-packaged class so I can use it in my code?



Simply put your "no-package" compiled classes in a separate jar file and include that jar in your deployment (WAR, EAR, other JAR or whatever your deployer wants).

(BTW wouldn't your "no-package" classes happen to be JasperReports generated classes? In such case I could give you a patch that generates them WITH package declaration.)

Cheers
20 years ago

Originally posted by Randall Stevens:
Is there anyone out there with an answer? Placing the files in the lib and creating the EAR did not seem to work in this situation.



Hi,
the solution is fairly easy and you don't need the APP-INF directory. Last time I checked, that trick was Weblogic specific.

1. Create a MANIFEST.MF file in a META-INF directory.
2. Reference all your third party jar files in your MANIFEST.MF file.
3. Create an new jar file. Call it something like "all_jars.jar"
4. Put all your third party jars in "all_jars.jar".
5. Include the META-INF (with MANIFEST.MF in it) in "all_jars.jar".
6. Include "all_jars.jar" in your ear file.
That's it. This works for instance with the following ear structure:

EAR
- webapp_module.WAR
- ejb_module.JAR
- app_commons.JAR
- all_jars.JAR

As an alternate (but sloppy) solution, you can also put all your third party jar files at the ear root and just add the /META-INF/MANIFEST.MF file as described earlier.

However, I've seen cases where third party tools use

stream = MyClass.class.getResourceAsStream(resource);

instead of

stream = Thread.currentThread().getContextClassLoader().getResourceAsStream(resource);

As a result, the classes in these jar files were able to find and load resources and other classes when their jar file was deployed in the server system classpath, but not when sitting inside an ear file.
In these rare cases, you have no other solution but to patch some of these tools' classes to make them use the currentThread context classloader.
One example of this is the Hibernate ORM framework which is unable to load its xml config file when both the Hibenate jar and the xml file are packaged inside an ear file.

I hope this helps.
Cheers