November 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-2577) isolating Hibernate as an internal impl detail

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2577?page=all ] Dimitris Andreadis updated JBAS-2577: ------------------------------------- Fix Version/s: JBossAS-5.0.0.Beta2 (was: JBossAS-5.0.0.Beta1) > isolating Hibernate as an internal impl detail > ---------------------------------------------- > > Key: JBAS-2577 > URL: http://jira.jboss.com/jira/browse/JBAS-2577 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Steve Ebersole > Assigned To: Steve Ebersole > Fix For: JBossAS-5.0.0.Beta2 > > > Currently Hibernate is used within JBossAS for EJB3 as well as the Hibernate-intg code, with plans/discussions to expand usage to JBoss Messaging and JBossMQ. This represents Hibernate usage as an internal implementation detail > Additionally, Hibernate is also used within JBossAS by user applications. This represents Hibernate usage as a deployment detail. > Currently, the two are not isolated from each other. Thus, a user attempting to bundle Hibernate with their application is actually using the Hibernate bundled with EJB3 and/or the integration code. This can cause problems when we have internal usage and external usage needing to rely on different releases of Hibernate. > Need to devise a scheme to isolate the internal usages of Hibernate. Two potential solutions: > 1) source-level import and package renaming of Hibernate code (i.e. org.jboss.hibernate) > 2) some form of classloader isolation -- 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

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3162) Testcase to validate set up of a root context web app

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3162?page=all ] Dimitris Andreadis updated JBAS-3162: ------------------------------------- Fix Version/s: JBossAS-5.0.0.Beta2 (was: JBossAS-5.0.0.Beta1) > Testcase to validate set up of a root context web app > ----------------------------------------------------- > > Key: JBAS-3162 > URL: http://jira.jboss.com/jira/browse/JBAS-3162 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: Anil Saldhana > Assigned To: Anil Saldhana > Priority: Minor > Fix For: JBossAS-4.2.0.CR1, JBossAS-5.0.0.Beta2 > > > Need to have a testcase that validates > http://wiki.jboss.org/wiki/Wiki.jsp?page=SetupARootContextApp -- 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

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1888) Incorrect variable expansion in org.jboss.util.propertyeditor.PropertiesEditor

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1888?page=all ] Dimitris Andreadis updated JBAS-1888: ------------------------------------- Fix Version/s: JBossAS-5.0.0.Beta2 (was: JBossAS-5.0.0.Beta1) > Incorrect variable expansion in org.jboss.util.propertyeditor.PropertiesEditor > ------------------------------------------------------------------------------ > > Key: JBAS-1888 > URL: http://jira.jboss.com/jira/browse/JBAS-1888 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Deployment services > Reporter: Bela Ban > Assigned To: Scott Marlow > Priority: Minor > Fix For: JBossAS-5.0.0.Beta2 > > > When I use the ${jboss.server.data.dir} variable in the example below, it is correctly expanded: > <attribute name="bla">${jboss.server.data.dir}</attribute> > However, when I use it in a Properties attribute, the expansion removes backslashes on Windows, e.g. in the example below: > <attribute name="CacheLoaderConfig"> > location = ${jboss.server.data.dir}/myCache > </attribute> > , I get c:JBoss3.2.7serverdefaultdata/myCache. > Scott Stark's reply: > The org.jboss.util.propertyeditor.PropertiesEditor which is what should be used for an attribute of type java.util.Properties does replace ${x} property references in values. The problem is that calling setProperty with the replacement value is not using an escaped string and so the win32 backslash is seen as a char escape sequence. Create a jira issue 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

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2391) Need to review PropertyManager

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2391?page=all ] Dimitris Andreadis updated JBAS-2391: ------------------------------------- Fix Version/s: JBossAS-5.0.0.Beta2 (was: JBossAS-5.0.0.Beta1) Move to Beta2 > Need to review PropertyManager > ------------------------------ > > Key: JBAS-2391 > URL: http://jira.jboss.com/jira/browse/JBAS-2391 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Deployment services > Affects Versions: JBossAS-4.0.3 Final > Reporter: Adrian Brock > Priority: Optional > Fix For: JBossAS-4.2.0.CR1, JBossAS-5.0.0.Beta2 > > > The PropertyManager installs itself as the system properties inorder to allow listeners to be registered > on property changes. > This should at least be configurable. -- 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

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1740) Remote Connection does not get closed in case of sloppy client

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1740?page=all ] Dimitris Andreadis updated JBAS-1740: ------------------------------------- Fix Version/s: JBossAS-5.0.0.Beta2 (was: JBossAS-5.0.0.Beta1) > Remote Connection does not get closed in case of sloppy client > -------------------------------------------------------------- > > Key: JBAS-1740 > URL: http://jira.jboss.com/jira/browse/JBAS-1740 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-4.0.1 Final > Reporter: Michael Kopp > Assigned To: Weston Price > Priority: Minor > Fix For: JBossAS-5.0.0.Beta2 > > > If the Client that gets a remote Connection (WrapperDataSourceService) does not close it properly (sloppy or crash), it will never be released again. > This can be solved rather easily, the finalize method of the Server part of the proxy should call close. > Thus if the client object gets garbage collected (or the JVM dies), the server object (proxy) will be garbage collected and the finalize method called. > This thing is that a sloppy or crashing client can occupy all available connections, leaving all other applications with no connection to work with. -- 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

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-2853) Integrate JBoss Cache 2.0 into AS 5.0

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2853?page=comments#action_12347024 ] Dimitris Andreadis commented on JBAS-2853: ------------------------------------------ JB5 Beta1 will use a JBC Alpha version. > Integrate JBoss Cache 2.0 into AS 5.0 > ------------------------------------- > > Key: JBAS-2853 > URL: http://jira.jboss.com/jira/browse/JBAS-2853 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JBoss Cache > Reporter: Manik Surtani > Assigned To: Manik Surtani > Priority: Critical > Fix For: JBossAS-5.0.0.Beta1 > > -- 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

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-2100) AOP integration in JBoss5

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2100?page=comments#action_12347023 ] Dimitris Andreadis commented on JBAS-2100: ------------------------------------------ Recap of the subtask dependencies by Kabir: BAOP-227 and JBAOP-109 - has been done, hoping for some input from Adrian before closing them. JBAOP-294 - we are now using a JDK 5 codebase, but I will create separate tasks for getting it to work in JDK 1.4 JBAOP-287 - I need a release of the "container" mc project, before I can do this, which in turn will affect the "aop-mc-int" mc project. This can be deferred til the next release though. JBAOP-304 - this is in progress, it has been done, but Brian keeps on "breaking it" :-) > AOP integration in JBoss5 > ------------------------- > > Key: JBAS-2100 > URL: http://jira.jboss.com/jira/browse/JBAS-2100 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: MicroContainer bus > Reporter: Adrian Brock > Assigned To: Kabir Khan > Priority: Blocker > Fix For: JBossAS-5.0.0.Beta1 > > > TODO: Bill > 1) Describe target AOP version and link the release task to this JBossAS integration task. > 2) Add extra integrations tasks/tests to this task. -- 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

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (SECURITY-21) Release 2.0.0.BETA

by Anil Saldhana (JIRA)

Release 2.0.0.BETA ------------------ Key: SECURITY-21 URL: http://jira.jboss.com/jira/browse/SECURITY-21 Project: JBoss Security Issue Type: Task Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: 2.0 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.0.BETA Tag and release 2.0.0.BETA of the Security SPI and JBossSX implementation for the JBoss 5.0.0.Beta release. -- 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

19 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-515) java NullPointerException when using constraints between fields in same object

by Sridhar Chandrasekharan (JIRA)

java NullPointerException when using constraints between fields in same object ------------------------------------------------------------------------------ Key: JBRULES-515 URL: http://jira.jboss.com/jira/browse/JBRULES-515 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.4 Environment: Linux Reporter: Sridhar Chandrasekharan Assigned To: Mark Proctor Consider the following files:- 1) Foo.java package com.foo; public class Foo { private int a; private int b; public Foo(int a, int b) { super(); this.a = a; this.b = b; } public boolean test() { return (a > b); } public int getA() { return a; } public int getB() { return b; } } ****************************************************************************** 2) FooTest.java package com.foo; import java.io.InputStreamReader; import java.io.*; import org.drools.RuleBase; import org.drools.RuleBaseFactory; import org.drools.WorkingMemory; import org.drools.compiler.PackageBuilder; import org.drools.rule.Package; public class FooTest { /** * This is a sample file to launch a rule package from a rule source file. */ public static final void main(String[] args) { try { //load up the rulebase RuleBase ruleBase = readRule(); WorkingMemory workingMemory = ruleBase.newWorkingMemory(); //go ! workingMemory.fireAllRules(); } catch (Throwable t) { t.printStackTrace(); } } /** * Please note that this is the "low level" rule assembly API. */ private static RuleBase readRule() throws Exception { //read in the source Reader source = new InputStreamReader( FooTest.class.getResourceAsStream( "/Foo.drl" ) ); //optionally read in the DSL (if you are using it). //Reader dsl = new InputStreamReader( DroolsTest.class.getResourceAsStream( "/mylang.dsl" ) ); //Use package builder to build up a rule package. //An alternative lower level class called "DrlParser" can also be used... PackageBuilder builder = new PackageBuilder(); //this wil parse and compile in one step //NOTE: There are 2 methods here, the one argument one is for normal DRL. builder.addPackageFromDrl( source ); //Use the following instead of above if you are using a DSL: //builder.addPackageFromDrl( source, dsl ); //get the compiled package (which is serializable) Package pkg = builder.getPackage(); //add the package to a rulebase (deploy the rule package). RuleBase ruleBase = RuleBaseFactory.newRuleBase(); ruleBase.addPackage( pkg ); return ruleBase; } } *************************************************** 3) Foo.drl package com.foo rule "Initialization rule" when #conditions then assert(new Foo(1,1)); assert(new Foo(2,1)); assert(new Foo(2,3)); assert(new Foo(3,2)); assert(new Foo(3,4)); assert(new Foo(4,3)); end rule "a greater than b" when f : Foo(x : a, b < x) then System.out.println("a=" + f.getA() + " b=" + f.getB() ); end ****************************************** I get the following error when running the program java.lang.NullPointerException at org.drools.rule.BoundVariableConstraint.isAllowed(Unknown Source) at org.drools.common.BetaNodeBinder.isAllowed(Unknown Source) at org.drools.reteoo.LeftInputAdapterNode.assertObject(Unknown Source) at org.drools.reteoo.ObjectSource.propagateAssertObject(Unknown Source) at org.drools.reteoo.ObjectTypeNode.assertObject(Unknown Source) at org.drools.reteoo.Rete.assertObject(Unknown Source) at org.drools.reteoo.ReteooRuleBase.assertObject(Unknown Source) at org.drools.reteoo.ReteooWorkingMemory.doAssertObject(Unknown Source) at org.drools.common.AbstractWorkingMemory.assertObject(Unknown Source) at org.drools.base.DefaultKnowledgeHelper.assertObject(Unknown Source) at org.drools.base.DefaultKnowledgeHelper.assertObject(Unknown Source) at com.foo.Rule_Initialization_rule_0.consequence(Rule_Initialization_rule_0.java:7) at com.foo.Rule_Initialization_rule_0ConsequenceInvoker.evaluate(Rule_Initialization_rule_0ConsequenceInvoker.java:18) at org.drools.common.DefaultAgenda.fireActivation(Unknown Source) at org.drools.common.DefaultAgenda.fireNextItem(Unknown Source) at org.drools.common.AbstractWorkingMemory.fireAllRules(Unknown Source) at org.drools.common.AbstractWorkingMemory.fireAllRules(Unknown Source) at com.foo.FooTest.main(FooTest.java:27) org.drools.spi.ConsequenceException: java.lang.NullPointerException at org.drools.common.DefaultAgenda.fireActivation(Unknown Source) at org.drools.common.DefaultAgenda.fireNextItem(Unknown Source) at org.drools.common.AbstractWorkingMemory.fireAllRules(Unknown Source) at org.drools.common.AbstractWorkingMemory.fireAllRules(Unknown Source) at com.foo.FooTest.main(FooTest.java:27) Caused by: java.lang.NullPointerException at org.drools.rule.BoundVariableConstraint.isAllowed(Unknown Source) at org.drools.common.BetaNodeBinder.isAllowed(Unknown Source) at org.drools.reteoo.LeftInputAdapterNode.assertObject(Unknown Source) at org.drools.reteoo.ObjectSource.propagateAssertObject(Unknown Source) at org.drools.reteoo.ObjectTypeNode.assertObject(Unknown Source) at org.drools.reteoo.Rete.assertObject(Unknown Source) at org.drools.reteoo.ReteooRuleBase.assertObject(Unknown Source) at org.drools.reteoo.ReteooWorkingMemory.doAssertObject(Unknown Source) at org.drools.common.AbstractWorkingMemory.assertObject(Unknown Source) at org.drools.base.DefaultKnowledgeHelper.assertObject(Unknown Source) at org.drools.base.DefaultKnowledgeHelper.assertObject(Unknown Source) at com.foo.Rule_Initialization_rule_0.consequence(Rule_Initialization_rule_0.java:7) at com.foo.Rule_Initialization_rule_0ConsequenceInvoker.evaluate(Rule_Initialization_rule_0ConsequenceInvoker.java:18) ... 5 more If I change the 2nd rule to rule "a greater than b" when f : Foo() and eval(f.test()) then System.out.println("a=" + f.getA() + " b=" + f.getB() ); end It works as expected. -- 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

19 years, 6 months

2
5
0 / 0

[JBoss JIRA] Updated: (JBAS-2251) Fix integration issues

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2251?page=all ] Dimitris Andreadis updated JBAS-2251: ------------------------------------- Fix Version/s: JBossAS-5.0.0.Beta2 (was: JBossAS-5.0.0.Beta1) Assignee: Manik Surtani Moving this to Beta2, assigning to Manik. > Fix integration issues > ---------------------- > > Key: JBAS-2251 > URL: http://jira.jboss.com/jira/browse/JBAS-2251 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: JBoss Cache > Reporter: Adrian Brock > Assigned To: Manik Surtani > Priority: Minor > Fix For: JBossAS-5.0.0.Beta2 > > > The JBossCache standalone build includes: > jboss-aop.jar (ok - should be standalone project) > jboss-common.jar (ok - should be standalone project(s)) > jboss-j2ee.jar (TransactionManager interfaces) > jboss-jmx.jar (only for JBossNotificationBroadcasterSupport leaking from jboss-system.jar?) > jboss-minimal.jar (for MarshalledValue, etc.) > jboss-system.jar (for ServiceMBeanSupport) > We are heading for a fall on this (not to mention the other thirdparty jars that could get out-of-sync) > Some of this will probably have to wait until we have the proper federated build. -- 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

19 years, 6 months

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 November 2006