This is always related to classpath problems. Make sure you have all dependencies set in your classpath and if that does not work, maybe make an> example project with the error available somewhere that another person can take a look at it. (don't think you can send zip attachements to the list, but not sure). Eclipse-plugin embeds a series of dependency jars that are transparently added to the classpath. That is the major reason you may see the problem outside of eclipse, but not inside. Classloader configuration is also another reason. []s Edson 2008/9/18 Soterro <send_lotsa_spam_here(a)yahoo.com&gt; > Hi all, > > I have a perfectly running Eclipse 3.3 with DRools 4.0.4 and JDK 1.5.14. > The rules are compiled with a post build Ant task which uses Janino (need > it for Tomcat compatibility). > Now OUTSIDE Eclipse it seems I cannot use that Ant task to save my life :( > I tried switching from Janino to the default compiler, same thing. I always > get this infamous error: > > BUILD FAILED > E:\buildRules-hudson.xml:30: RuleBaseTask failed: Unable to load dialect > 'org.drools.rule.builder.dialect.java.JavaDialectConfiguration:java' > at > com.csc.ezbook.eztarif.rules.DroolsCompilerAntTaskStandalone.execute > (DroolsCompilerAntTaskStandalone.java:163) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java > :105) > at org.apache.tools.ant.Task.perform(Task.java:348) > [...] > Caused by: org.drools.RuntimeDroolsException: Unable to load dialect > 'org.drools.rule.builder.dialect.java.JavaDialectConfiguration:java' > at org.drools.compiler.PackageBuilderConfiguration.addDialect( > PackageBuilderConfiguration.java:152) > at org.drools.compiler.PackageBuilderConfiguration. > buildDialectConfigurationMap(PackageBuilderConfiguration.java:140) > at org.drools.compiler.PackageBuilderConfiguration.init( > PackageBuilderConfiguration.java:117) > at org.drools.compiler.PackageBuilderConfiguration.<init>( > PackageBuilderConfiguration.java:94) > at > com.my.app.rules.DroolsCompilerAntTaskStandalone.getPackageBuilder( > DroolsCompilerAntTaskStandalone.java:257) > at com.my.app.rules.DroolsCompilerAntTaskStandalone.execute( > DroolsCompilerAntTaskStandalone.java:136) > > That "DroolsCompilerAntTaskStandalone" is my task using the default > compiler like this: > PackageBuilderConfiguration conf = new PackageBuilderConfiguration(); > conf.setClassLoader( loader ); > PackageBuilder builder = new PackageBuilder( conf ); > > If I use Janino like below the error is exactly the same... > PackageBuilderConfiguration pkgBuilderCfg = new > PackageBuilderConfiguration(); > pkgBuilderCfg.setClassLoader( loader ); > JavaDialectConfiguration javaConf = (JavaDialectConfiguration) > pkgBuilderCfg.getDialectConfiguration( "java" ); > javaConf.setCompiler( JavaDialectConfiguration.JANINO ); > PackageBuilder builder = new PackageBuilder( pkgBuilderCfg ); > > Again, in Eclipse all is working fine. I checked Ant's classpath, here it > is: > E:\apache-ant-1.7.0\bin\..\lib\ant-launcher.jar > E:\apache-ant-1.7.0\lib\*.jar > C:\Program Files\Java\jdk1.5.0_14\lib\tools.jar > > Here is how I provide a classpath: > <taskdef name="rulescompiler" classname="com.my.app.rules. > DroolsCompilerAntTaskStandalone" > classpathref="droolsutils.classpath" /> > > <target depends="newfilesarethere" name="build" > unless="rulesCompile. > notRequired"> > <rulescompiler srcdir="${THIS_PROJ}/src/com/my/app/rules" > > tofile="${THIS_PROJ}/build/classes/com/my/app/rules/ > packaged.rules" > classpathref="droolsutils.classpath" > > <include name="*.drl" /> > </rulescompiler> > </target> > > The classpath I provide contains pretty much all libraries I use normally > in the project, but I tried even to add ALL jar's from the Eclipse 3.3 > install directory (that would include all DRools 4.0.4 libraries, with antlr > and whatnot) > > I tried also with DRools 4.0.7, same behaviour... > > What does that mean and where is it coming from? Could it have issues with > the tools.jar from Java 1.5.0_14? > > Thank you for any input, > M > > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > -- Edson Tirelli JBoss Drools Core Development JBoss, a division of Red Hat @ www.jboss.com

Thanks a lot for the answer. The problem is exactly that one: how could I know what the dependencies for the DRools compiler are?! I thought this list would know :)) Anyway, I'll print out the Eclipse runtime classpath and compare them two to see what stands out. The Ant task is mentioned here and there in the documentation (albeit without examples) so I kinda thought more people are using it. An older thread of this same list talks about adding (only) the drools-ant to the classpath, which of course solves the ant task itself but none of its dependencies... I find it difficult to believe that the compiler depends on some Eclipse stuff, especially after I added ALL the jars existing in the Eclipse configuration. The only thing I cannot directly rule out is the classloader issue, but that's also the only thing I have no idea how to debug/solve :( Thank you, M --- On Sun, 9/21/08, Edson Tirelli <tirelli(a)post.com&gt; wrote: > This is always related to classpath problems. Make sure you have all > dependencies set in your classpath and if that does not work, maybe > make an> example project with the error available somewhere that > another person can take a look at it. (don't think you can send zip > attachements to the list, but not sure). > > Eclipse-plugin embeds a series of dependency jars that are > transparently added to the classpath. That is the major reason you may > see the problem outside of eclipse, but not inside. Classloader > configuration is also another reason. > > []s > Edson > > 2008/9/18 Soterro <send_lotsa_spam_here(a)yahoo.com&gt; > > >> Hi all, >> >> I have a perfectly running Eclipse 3.3 with DRools >> > 4.0.4 and JDK 1.5.14. > >> The rules are compiled with a post build Ant task >> > which uses Janino (need > >> it for Tomcat compatibility). >> Now OUTSIDE Eclipse it seems I cannot use that Ant >> > task to save my life :( > >> I tried switching from Janino to the default compiler, >> > same thing. I always > >> get this infamous error: >> >> BUILD FAILED >> E:\buildRules-hudson.xml:30: RuleBaseTask failed: >> > Unable to load dialect > > 'org.drools.rule.builder.dialect.java.JavaDialectConfiguration:java' > >> at >> >> > com.csc.ezbook.eztarif.rules.DroolsCompilerAntTaskStandalone.execute > >> (DroolsCompilerAntTaskStandalone.java:163) >> at >> >> > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) > >> at >> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >> at >> >> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > >> java:39) >> at >> > sun.reflect.DelegatingMethodAccessorImpl.invoke( > >> DelegatingMethodAccessorImpl.java:25) >> at >> > java.lang.reflect.Method.invoke(Method.java:585) > >> at >> >> > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java > >> :105) >> at >> > org.apache.tools.ant.Task.perform(Task.java:348) > >> [...] >> Caused by: org.drools.RuntimeDroolsException: Unable >> > to load dialect > > 'org.drools.rule.builder.dialect.java.JavaDialectConfiguration:java' > >> at >> > org.drools.compiler.PackageBuilderConfiguration.addDialect( > >> PackageBuilderConfiguration.java:152) >> at >> > org.drools.compiler.PackageBuilderConfiguration. > >> >> > buildDialectConfigurationMap(PackageBuilderConfiguration.java:140) > >> at >> > org.drools.compiler.PackageBuilderConfiguration.init( > >> PackageBuilderConfiguration.java:117) >> at >> > org.drools.compiler.PackageBuilderConfiguration.<init>( > >> PackageBuilderConfiguration.java:94) >> at >> >> > com.my.app.rules.DroolsCompilerAntTaskStandalone.getPackageBuilder( > >> DroolsCompilerAntTaskStandalone.java:257) >> at >> > com.my.app.rules.DroolsCompilerAntTaskStandalone.execute( > >> DroolsCompilerAntTaskStandalone.java:136) >> >> That "DroolsCompilerAntTaskStandalone" is my >> > task using the default > >> compiler like this: >> PackageBuilderConfiguration conf = new >> > PackageBuilderConfiguration(); > >> conf.setClassLoader( loader ); >> PackageBuilder builder = new PackageBuilder( conf >> > ); > >> If I use Janino like below the error is exactly the >> > same... > >> PackageBuilderConfiguration pkgBuilderCfg = new >> PackageBuilderConfiguration(); >> pkgBuilderCfg.setClassLoader( loader ); >> JavaDialectConfiguration javaConf = >> > (JavaDialectConfiguration) > >> pkgBuilderCfg.getDialectConfiguration( >> > "java" ); > >> javaConf.setCompiler( >> > JavaDialectConfiguration.JANINO ); > >> PackageBuilder builder = new PackageBuilder( >> > pkgBuilderCfg ); > >> Again, in Eclipse all is working fine. I checked >> > Ant's classpath, here it > >> is: >> >> > E:\apache-ant-1.7.0\bin\..\lib\ant-launcher.jar > >> E:\apache-ant-1.7.0\lib\*.jar >> C:\Program >> > Files\Java\jdk1.5.0_14\lib\tools.jar > >> Here is how I provide a classpath: >> <taskdef name="rulescompiler" >> > classname="com.my.app.rules. > >> DroolsCompilerAntTaskStandalone" >> classpathref="droolsutils.classpath" /> >> >> <target depends="newfilesarethere" >> > name="build" > >> unless="rulesCompile. >> notRequired"> >> <rulescompiler >> > srcdir="${THIS_PROJ}/src/com/my/app/rules" > >> > tofile="${THIS_PROJ}/build/classes/com/my/app/rules/ > >> packaged.rules" >> >> > classpathref="droolsutils.classpath" > > >> <include name="*.drl" >> > /> > >> </rulescompiler> >> </target> >> >> The classpath I provide contains pretty much all >> > libraries I use normally > >> in the project, but I tried even to add ALL jar's >> > from the Eclipse 3.3 > >> install directory (that would include all DRools 4.0.4 >> > libraries, with antlr > >> and whatnot) >> >> I tried also with DRools 4.0.7, same behaviour... >> >> What does that mean and where is it coming from? Could >> > it have issues with > >> the tools.jar from Java 1.5.0_14? >> >> Thank you for any input, >> M >> >> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss, a division of Red Hat @ www.jboss.com > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Well it clearly is a problem with filters as the following works in WebSphere: http://localhost:9080/drools-guvnor/index.jsp However just typing http://localhost:9080/drools-guvnor does not and gives you the Ugly 500. Cheers, Vikrant From: Vikrant Yagnick Sent: Monday, September 22, 2008 4:38 PM To: Rules Users List Subject: Deploying the BRMS on Web-Sphere 6.1 Hi All, Has anyone been able to deploy the BRMS War file on Websphere 6.1. The BRMS deploys without problems , but I get the following error when I try to access the BRMS: Error 500: com.ibm.ws.wswebcontainer.extension.DefaultExtensionProcessor incompatible with com.ibm.wsspi.webcontainer.servlet.IServletWrapper. However, the WebDAV servlet still works. I dug around a little, and have found that this problem has occurred for other web-applications as well who have provided a workaround: http://wiki.merbivore.com/pages/deploying-a-merb-application-to-a-jee-con... (Read Step 7) The problem seems to be related to Servlet-Filters. These do not seem to work correctly with Websphere 6.1. In the site mentioned they have replaced the servlet-filter with a normal server. (The BRMS seems to use a servlet filter for /* url mapping). I have seen posts on other forums regarding the BRMS deployment on Websphere 6.1 but no answers as to how to make this work. Any, help would be appreciated. Cheers, Vikrant MASTEK LTD. Mastek is in NASSCOM's 'India Top 20' Software Service Exporters List. In the US, we're called MAJESCOMASTEK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in error, kindly delete this e-mail from desktop and server. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Well it is not that serious a problem as I initially thought. As I mentioned the URL(adding the index.jsp) works, so there is an easy work-around available. The main bug seems to be that if a URL is sent to WebSphere which does not have a physical file in it the filter which should kick in and re-direct does not do so. (http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PK27620 ) This has nothing to do with the BRMS of course and is a problem for all Web-Apps in this version of Websphere(We are using 6.1.0.0). Adding the index.jsp to the URL seems to work fine for now. I am working on the BRMS to see if there are any other side-effects of this. Maybe, we should update a Wiki or troubleshooting doc on this so that it is known to the community. Digging around IBM Support after my post, I have found quite a few bugs mentioned in version 6.1 regarding how Servlet Filters work and of some on JSF(Especially JBOSS Seam) problems with the particular version. (http://www-01.ibm.com/support/docview.wss?uid=swg1PK47367) IBM has however provided patches for all of them and I am going to give another shot at seeing the behavior after upgrading to a higher release. -----Original Message----- From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org ] On Behalf Of Michael Neale Sent: Tuesday, September 23, 2008 5:25 AM To: Rules Users List Subject: Re: [rules-users] RE: Deploying the BRMS on Web-Sphere 6.1 Hi Vikrant. well the drools-guvnor/ doesn't use a filter so much as it is default web.xml behaviour - you can specify a "welcome" page, which it goes to when the root path is supplied. If Websphere 6.1 can't even do that - I would say something is seriously wrong (may be a bad install?) - you could try it with a really simple war that just has 1 jsp and a web.xml and see if it happens with it? although I think: As for servlet filters - as we use Seam, it uses servlet filters to manage lifecycles, so yes, that could be it (if its not the above). It isn't possible to replace the filters, as they do a very different job from servlets (although the difference is subtle). What would be better would be to work out what the problem is with websphere and filters I think. On Mon, Sep 22, 2008 at 9:34 PM, Vikrant Yagnick <VikrantY(a)mastek.com&gt; wrote: > Well it clearly is a problem with filters as the following works in > WebSphere: > > > > http://localhost:9080/drools-guvnor/index.jsp > > > > However just typing > > > > http://localhost:9080/drools-guvnor does not and gives you the Ugly > 500. > > > > > > Cheers, > > Vikrant > > > > From: Vikrant Yagnick > Sent: Monday, September 22, 2008 4:38 PM > To: Rules Users List > Subject: Deploying the BRMS on Web-Sphere 6.1 > > > > Hi All, > > > > Has anyone been able to deploy the BRMS War file on Websphere 6.1. > The BRMS > deploys without problems , but I get the following error when I try > to > access the BRMS: > > > > Error 500: > com.ibm.ws.wswebcontainer.extension.DefaultExtensionProcessor > incompatible with com.ibm.wsspi.webcontainer.servlet.IServletWrapper. > > > > However, the WebDAV servlet still works. > > I dug around a little, and have found that this problem has > occurred for > other web-applications as well who have provided a workaround: > > > > http://wiki.merbivore.com/pages/deploying-a-merb-application-to-a-jee-con... > (Read Step 7) > > > > The problem seems to be related to Servlet-Filters. These do not > seem to > work correctly with Websphere 6.1. In the site mentioned they have > replaced > the servlet-filter with a normal server. (The BRMS seems to use a > servlet > filter for /* url mapping). > > > > I have seen posts on other forums regarding the BRMS deployment on > Websphere > 6.1 but no answers as to how to make this work. > > > > Any, help would be appreciated. > > > > Cheers, > > Vikrant > > > > > > > MASTEK LTD. > Mastek is in NASSCOM's 'India Top 20' Software Service Exporters > List. > In the US, we're called MAJESCOMASTEK > > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Opinions expressed in this e-mail are those of the individual and > not that of Mastek Limited, unless specifically indicated to that > effect. Mastek Limited does not accept any responsibility or > liability for it. This e-mail and attachments (if any) transmitted > with it are confidential and/or privileged and solely for the use > of the intended person or entity to which it is addressed. Any > review, re-transmission, dissemination or other use of or taking of > any action in reliance upon this information by persons or entities > other than the intended recipient is prohibited. This e-mail and > its attachments have been scanned for the presence of computer > viruses. It is the responsibility of the recipient to run the virus > check on e-mails and attachments before opening them. If you have > received this e-mail in error, kindly delete this e-mail from > desktop and server. > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users MASTEK LTD. Mastek is in NASSCOM's 'India Top 20' Software Service Exporters List. In the US, we're called MAJESCOMASTEK ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in error, kindly delete this e-mail from desktop and server. ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users