Something worth trying (it keeps catching me out) ... If I have been adding & removing classes from a jar, I see this frequently. I worked out that I need to open my Guvnor package and switch to the "edit" tab. There's a list of "Imported Types". You may well find that 'missing' facts are still in that list, so you just need to remove them. Basically, if you remove a class from your model, the imported class doesn't get dropped from this list automatically, and you see the class not found errors. When I get these kinds of errors, I generally just remove all classes from that list and re-import the POJO model jar, which automatically re-populates the list with the facts from my jar. Steve On 3 Sep 2012, at 12:17, &quot;devan.vanreenen(a)gmail.com&quot; <devan.vanreenen(a)gmail.com&gt; wrote:

Are you sure that this specific jar/class does not depends of other external (from java/drools point of view) classes ? Does it work if you download the generated DRL, and compile/run it outside Guvnor ? ----- Mail original ----- De: "devan vanreenen" <devan.vanreenen(a)gmail.com&gt; À: rules-users(a)lists.jboss.org Envoyé: Lundi 3 Septembre 2012 13:49:00 Objet: Re: [rules-users] ClassNotFoundException Thanks for the response Steve, the only imports I have are specifically for objects I use within my rules, I have removed all the imports for the "problematic" jar as well as any imports for objetcs not used in the rules and tried using the fully qualified names of the classes in the rules, still no luck. There are no issues with my other jars just a specific one, I deleted this jar and uploaded again. -- View this message in context: http://drools.46999.n3.nabble.com/ClassNotFoundException-tp4019536p401954... Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

All needed classes must be known by java classloader at compile time ... recusively ... and indeed, this can lead to massive jar addition in the classpath. Hibernate uses a lot of other jars too, you must add them as well ... That's exactly the reason why I try (as much as I can) to make a POJO model for rules that depends on nothing. For instance, I use Hibernate with xml config files and not annotations (otherwise it make the POJO model dependant of Hibernate jar ...) You can either add directly some jars in tomcat "lib" folder , or under guvnor's lib (directly in war file) if these jars does not change too often...

Where Vincent mentions using XML config for adding persistence to simple POJO models, something I started experimenting with a while back, was to create very basic fact models in one project and have a separate project which added persistence and other features using AOP. I don't suppose anyone else has played with that idea and had much success? I was finding some 'aspects' of AOP somewhat messy (for one thing, my Eclipse IDE tended to fall over). In case you're using Maven, here are a few things I have used on different occasions to help with the external dependencies issue. You may well be doing something like this anyway, but just in case… 1. Define a child project which only contains only your fact model, and make sure you do not import any dependencies! A lot of boilerplate config, but you will end up with a Jar containing only those facts you define. If your project compiles, then you know for sure that you don't have any external dependencies. 2. Use the Maven Jar plugin to generate a Jar, which only contains your facts: Neat if you already have a project with some model classes, and you want to ensure that the POJO you upload only contains facts required by Guvnor. Example: https://gist.github.com/3609258 3. Use the Maven Shade plugin to generate a Jar containing your facts and absolutely every dependency it has: Using this bad boy will almost certainly give you a load of grief if you try using it as your POJO model Jar. But if you're whacking Jars in a Tomcat lib directory, then it can be a good way of keeping the number of Jars under control. i.e. You only need to release a single Jar file and it contains all the dependencies you need. Example: https://gist.github.com/3609269 Steve On 3 Sep 2012, at 13:08, &quot;devan.vanreenen(a)gmail.com&quot; <devan.vanreenen(a)gmail.com&gt; wrote: