July 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-378) NoClassDefFoundError at org.drools.compiler.PackageBuilder.loadCompiler

by Mihai Florea (JIRA)

NoClassDefFoundError at org.drools.compiler.PackageBuilder.loadCompiler ----------------------------------------------------------------------- Key: JBRULES-378 URL: http://jira.jboss.com/jira/browse/JBRULES-378 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.0.2 Environment: -Linux 2.4.26; -Sun JDK 1.5.0_06; -Eclipse 3.2.0 M20060629-1905; -Jar classpath entries: antlr-2.7.6.jar antlr-3.0ea8.jar colt-1.2.0.jar commons-collections-3.1.jar commons-io-1.1.jar commons-jci-core-1.0-406301.jar commons-jci-eclipse-3.2.0.666.jar commons-jci-janino-2.4.3.jar commons-lang-2.1.jar commons-logging-api-1.0.4.jar concurrent-1.3.4.jar drools-compiler.jar drools-core.jar drools-decisiontables.jar drools-jsr94.jar janino-2.4.3.jar jsr94-1.1.jar jung-1.7.2.jar junit-3.8.1.jar poi-2.5.1-final-20040804.jar stringtemplate-2.3b6.jar xercesImpl-2.6.2.jar xml-apis-1.0.b2.jar xpp3-1.1.3.4.O.jar xstream-1.1.3.jar Reporter: Mihai Florea Assigned To: Mark Proctor When trying to run the HelloWorldExample from drools-samples, I ended up with the following error: java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/compiler/env/INameEnvironment at org.drools.compiler.PackageBuilder.loadCompiler(Unknown Source) at org.drools.compiler.PackageBuilder.<init>(Unknown Source) at org.drools.compiler.PackageBuilder.<init>(Unknown Source) at org.drools.examples.HelloWorldExample.readRule(HelloWorldExample.java:49) at org.drools.examples.HelloWorldExample.main(HelloWorldExample.java:21) The "eclipse" part from the error message seemed quite to me strange since I specified it to use the Janino compiler with -Ddrools.compiler=JANINO -Ddrools.compiler.lnglevel=1.4 I was running the example from within Eclipse, having all the required libraries in classpath (not the DROOLS/JBoss Rules library, but the jar files added manually). Taking a look at "loadCompiler()" method in org.drools.compiler.PackageBuilder, I noticed a missing break in the switch statement, which is the cause of the problem IMHO. private void loadCompiler() { switch ( configuration.getCompiler() ) { case PackageBuilderConfiguration.JANINO : { if ( !"1.4".intern().equals( configuration.getJavaLanguageLevel() ) ) throw new RuntimeDroolsException( "Incompatible Java language level with selected compiler" ); compiler = JavaCompilerFactory.getInstance().createCompiler("janino"); } // I believe we should have a "break" statement at this line, unless we want the system properties to be ignored case PackageBuilderConfiguration.ECLIPSE : default : { EclipseJavaCompilerSettings eclipseSettings = new EclipseJavaCompilerSettings(); eclipseSettings.getMap().put( "org.eclipse.jdt.core.compiler.codegen.targetPlatform", configuration.getJavaLanguageLevel() ); eclipseSettings.getMap().put( "org.eclipse.jdt.core.compiler.source", configuration.getJavaLanguageLevel() ); compiler = new EclipseJavaCompiler( eclipseSettings ); } } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

20 years

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-703) Remove does not work anymore using non-String keys

by Benjamin Papez (JIRA)

Remove does not work anymore using non-String keys -------------------------------------------------- Key: JBCACHE-703 URL: http://jira.jboss.com/jira/browse/JBCACHE-703 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.0 Reporter: Benjamin Papez Assigned To: Manik Surtani Priority: Blocker I am using the following, while getFqn() is a Fqn-object of an existing tree node like "/FieldsCache" and entry is any object. getTreeCache().put(new Fqn(getFqn(), new Integer(10)), "entry", entry); getTreeCache().get(new Fqn(getFqn(), new Integer(10)), "entry"); getTreeCache().remove(new Fqn(getFqn(), new Integer(10))); Since switching to jbosscache 1.4.0.GA (did not test with the betas) the remove will not really remove the item, will also not throw an exception and if I issue another get after the remove the node will again be returned. I am using pessimistic locking with either READ_UNCOMMITED or even NONE as locking level. When debugging I see in the _remove method on line 4537 that the parent_node.removeChild(n.getName()); does not work, because n.getName() returns a String, while the childrenNames in the parent_node have Integers as keys. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

20 years

2
1
0 / 0

[JBoss JIRA] Resolved: (JBPORTAL-942) Update quickstart guide for 2.4.

by Roy Russo (JIRA)

[ http://jira.jboss.com/jira/browse/JBPORTAL-942?page=all ] Roy Russo resolved JBPORTAL-942. -------------------------------- Fix Version/s: 2.4 Final Resolution: Done > Update quickstart guide for 2.4. > -------------------------------- > > Key: JBPORTAL-942 > URL: http://jira.jboss.com/jira/browse/JBPORTAL-942 > Project: JBoss Portal > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documentation > Affects Versions: 2.4 Final > Reporter: Roy Russo > Assigned To: Roy Russo > Fix For: 2.4 Final > > Attachments: quickstartuser.zip > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

20 years

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3401) NPE in jdk5 javax.management.MBeanOperationInfo.equals() (affects jmx-console)

by Dimitris Andreadis (JIRA)

NPE in jdk5 javax.management.MBeanOperationInfo.equals() (affects jmx-console) ------------------------------------------------------------------------------ Key: JBAS-3401 URL: http://jira.jboss.com/jira/browse/JBAS-3401 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Management services Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta The javax.management.MBeanOperationInfo.equals() of jdk5 produces NPEs when any field of the "other" object is null: public boolean equals(Object o) { if (o == this) return true; if (!(o instanceof MBeanOperationInfo)) return false; MBeanOperationInfo p = (MBeanOperationInfo) o; return (p.getName().equals(getName()) && p.getReturnType().equals(getReturnType()) && p.getDescription().equals(getDescription()) && p.getImpact() == getImpact() && Arrays.equals(p.fastGetSignature(), fastGetSignature())); } This could be a jdk bug, however the problem appears in when viewing the MainDeployer mbean through the jmx-console, due to the descriptor field of some "deploy" operation being null in the xmbean descriptor. org.apache.jasper.JasperException: Exception in JSP: /inspectMBean.jsp:94 91: { 92: MBeanOperationInfo opInfo = operationInfo[a]; 93: System.out.println(String.valueOf(a) + opInfo); 94: operationInfoIndexMap.put(opInfo, String.valueOf(a)); 95: } 96: 97: Arrays.sort(operationInfo, MBEAN_FEATURE_INFO_COMPARATOR); root cause java.lang.NullPointerException javax.management.MBeanOperationInfo.equals(MBeanOperationInfo.java:209) java.util.HashMap.eq(HashMap.java:277) java.util.HashMap.put(HashMap.java:386) org.apache.jsp.inspectMBean_jsp._jspService(inspectMBean_jsp.java:155) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) The problem doesn't affect Branch_4_0, since the inspectMBean.jsp code is different -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

20 years

1
1
0 / 0

[JBoss JIRA] Commented: (JBESB-56) Update Getting Started Guide to reflect paramsFactory change

by Daniel Brum (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-56?page=comments#action_12339751 ] Daniel Brum commented on JBESB-56: ---------------------------------- Jason, if you need help with this, please ask Esteban on the mail list for more info. > Update Getting Started Guide to reflect paramsFactory change > ------------------------------------------------------------ > > Key: JBESB-56 > URL: http://jira.jboss.com/jira/browse/JBESB-56 > Project: JBoss ESB > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documentation > Affects Versions: 4.0 Beta 1 > Reporter: Daniel Brum > Assigned To: Jason Lenhart > Priority: Minor > Fix For: 4.0 Beta 1 > > > Need the Getting Started Guide updated to reflect the new paramsFactory design - re: ldap or file, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

20 years

1
0
0 / 0

[JBoss JIRA] Closed: (JBTM-91) Fix the supported database and driver tables in the documentation

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBTM-91?page=all ] Mark Little closed JBTM-91. --------------------------- Resolution: Done Committed new Word and pdf documents. > Fix the supported database and driver tables in the documentation > ----------------------------------------------------------------- > > Key: JBTM-91 > URL: http://jira.jboss.com/jira/browse/JBTM-91 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Documentation > Affects Versions: 4.2 > Reporter: Mark Little > Assigned To: Mark Little > Fix For: 4.2.1 > > Time Spent: 1 hour > Remaining Estimate: 0 minutes > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

20 years

1
0
0 / 0

[JBoss JIRA] Updated: (EJBTHREE-524) implement <unauthenticated-principal> in jboss.xml

by William DeCoste (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-524?page=all ] William DeCoste updated EJBTHREE-524: ------------------------------------- Fix Version/s: EJB 3.0 RC9 - FD > implement <unauthenticated-principal> in jboss.xml > -------------------------------------------------- > > Key: EJBTHREE-524 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-524 > Project: EJB 3.0 > Issue Type: Task > Affects Versions: EJB 3.0 RC6 - PFD > Reporter: William DeCoste > Assigned To: William DeCoste > Fix For: EJB 3.0 RC9 - FD > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

20 years

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-100) Update release notes for patches to 4.2.

by Mark Little (JIRA)

Update release notes for patches to 4.2. ---------------------------------------- Key: JBTM-100 URL: http://jira.jboss.com/jira/browse/JBTM-100 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.2 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.2.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

20 years

1
1
0 / 0

[JBoss JIRA] Commented: (JBCACHE-674) PojoCache to handle simultaneous pojo attach on the clustering nodes

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-674?page=comments#action_12339742 ] Ben Wang commented on JBCACHE-674: ---------------------------------- Further thoughs on this issue. It is really difficult to implement a callback mechanism for pojo update callback. For one, I can't differentitate what is field and what is whole pojo update. So one workaround maybe just to document the usage that if the clustering node are all active (e.g., each node can do attach simultaneously), the best practice is then: cacheA.attach("1", pojo1); pojo1 = cacheA.find("1"); cacheB.attach("1", pojo2); pojo2 = cacheB.find("1"); that is, after doing attach, we will always do another find again to retrieve the latest version. If it has been updated, PojoCache will recontruct the POJO instance. If not, the operation will return right away. > PojoCache to handle simultaneous pojo attach on the clustering nodes > -------------------------------------------------------------------- > > Key: JBCACHE-674 > URL: http://jira.jboss.com/jira/browse/JBCACHE-674 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: POJOCache > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Currently we don't handle cases with active attachment of pojo on all clustering nodes. For example, > cacheA.attach("1", pojo1); > cacheB.attach("1", pojo2); > pojo2 will overwrite pojo1 but pojo1 will still have cache interceptor attached to it. So solution will have to be some sort of check dirty mechanism when any POJO operation is called. But this will introduce more overheads. > Still need to gather more use case for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

20 years

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-54) PojoCache needs a customized interceptor option

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-54?page=all ] Ben Wang resolved JBCACHE-54. ----------------------------- Fix Version/s: 2.0.0 (was: POJOCache) Resolution: Done > PojoCache needs a customized interceptor option > ----------------------------------------------- > > Key: JBCACHE-54 > URL: http://jira.jboss.com/jira/browse/JBCACHE-54 > Project: JBoss Cache > Issue Type: Feature Request > Components: PojoCache > Affects Versions: 1.2.1 > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.0.0 > > Original Estimate: 4 weeks > Remaining Estimate: 4 weeks > > In designing the implementation of http session repl using JBossCacheAop, there is a need to add a customized interceptor (in addition to the CacheInterceptor) to handle specific session request. > This feature can be generalized to a generic customized interceptor chain that a user of aop can add to his own. Idea then is the chain (of which starts with the CacheInterceptor) will be added as a dynamic aop interceptors. > This requires refactoring of current TreeCacheAop such that certain method calls can be expressed a pointcut such that we can bind customized interceptors there. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

20 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2006