August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-3358) Work directory shouldn't be deleted on Context Destroy

by Anil Saldhana (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3358?page=all ] Anil Saldhana updated JBAS-3358: -------------------------------- Summary: Work directory shouldn't be deleted on Context Destroy (was: Work directory shouldn't be deleted) > Work directory shouldn't be deleted on Context Destroy > ------------------------------------------------------ > > Key: JBAS-3358 > URL: http://jira.jboss.com/jira/browse/JBAS-3358 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Affects Versions: JBossAS-4.0.4.GA > Reporter: Javid Jamae > Assigned To: Anil Saldhana > Fix For: JBossAS-4.0.5.GA > > > I tried enabling HTTP session persistence, but found out that the default directory that it writes to is the work directory. Working with JBoss support, I discovered that the work directory is deleted when the server shuts down. > Either the work directory should not be deleted, or the default directory where the persistent HTTP sessions are serialized to a file should be changed to be in a directory other than work (since it is being deleted). -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAOP-269) Contention point in MethodMetaData

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-269?page=comments#action_12341194 ] Kabir Khan commented on JBAOP-269: ---------------------------------- Did you perform the tests? > Contention point in MethodMetaData > ---------------------------------- > > Key: JBAOP-269 > URL: http://jira.jboss.com/jira/browse/JBAOP-269 > Project: JBoss AOP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Kabir Khan > Assigned To: Kabir Khan > Fix For: 2.0, 1.5.1.GA > > -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAOP-243) ${instanceof} disregards method call target

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-243?page=all ] Kabir Khan updated JBAOP-243: ----------------------------- Fix Version/s: (was: 1.5.1.GA) > ${instanceof} disregards method call target > ------------------------------------------- > > Key: JBAOP-243 > URL: http://jira.jboss.com/jira/browse/JBAOP-243 > Project: JBoss AOP > Issue Type: Bug > Affects Versions: 1.3.5 > Reporter: Konstantin Sobolev > Fix For: 2.0 > > Attachments: jbaop-243.tar.gz > > > instanceof{$I}->method() checks a class declaring method() instead of the class on which this method is actually called. > Example: > interface I1 {void foo();} > interface I2 {void bar();} > class I1Impl implements I1 {void foo(){};} > class Target extends I1Impl implements I2 {void bar();} > now $instanceof{I1}->foo() will intercept new Target.foo(), while > ${instanceof{I1}->bar() won't intercept new Target.bar(). > Testcase implementing this example is attached. > Please see forum thread for a real life example. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-3358) Work directory shouldn't be deleted

by Anil Saldhana (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3358?page=comments#action_12341192 ] Anil Saldhana commented on JBAS-3358: ------------------------------------- http://issues.apache.org/bugzilla/show_bug.cgi?id=35819 This is the change that has happened in TC 5.5.10 onwards. > Work directory shouldn't be deleted > ----------------------------------- > > Key: JBAS-3358 > URL: http://jira.jboss.com/jira/browse/JBAS-3358 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Affects Versions: JBossAS-4.0.4.GA > Reporter: Javid Jamae > Assigned To: Anil Saldhana > Fix For: JBossAS-4.0.5.GA > > > I tried enabling HTTP session persistence, but found out that the default directory that it writes to is the work directory. Working with JBoss support, I discovered that the work directory is deleted when the server shuts down. > Either the work directory should not be deleted, or the default directory where the persistent HTTP sessions are serialized to a file should be changed to be in a directory other than work (since it is being deleted). -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBRULES-30) Create Runtime Deployment utility

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-30?page=all ] Mark Proctor closed JBRULES-30. ------------------------------- Resolution: Duplicate Issue > Create Runtime Deployment utility > --------------------------------- > > Key: JBRULES-30 > URL: http://jira.jboss.com/jira/browse/JBRULES-30 > Project: JBoss Rules > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 3.0-beta1 > Reporter: Michael Neale > Assigned To: Michael Neale > Priority: Optional > Original Estimate: 2 days > Remaining Estimate: 2 days > > Runtime deployment utility it a component which is deployed where the rule engine executions. > Its features: > * Pull a ruleset (or collection of) from a Repository, build and cache > * Use a properties file to configure what rulesets/tags to be extracted (so you can use different configs based on the server that runs the component) > * Use Shotoku utility so it can be applied to JCR and other "repositories" in future. > This is done, and is in drools-repository/runtime-deployer (the svn plug in is next to it) -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Deleted: (JBMESSAGING-184) Transparent client fail-over

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-184?page=all ] Tim Fox deleted JBMESSAGING-184: -------------------------------- > Transparent client fail-over > ---------------------------- > > Key: JBMESSAGING-184 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-184 > Project: JBoss Messaging > Issue Type: Feature Request > Reporter: Ovidiu Feodorov > Assigned To: Ovidiu Feodorov > -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBRULES-47) Named Facts

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-47?page=all ] Mark Proctor updated JBRULES-47: -------------------------------- Fix Version/s: (was: 3.1-m3) > Named Facts > ----------- > > Key: JBRULES-47 > URL: http://jira.jboss.com/jira/browse/JBRULES-47 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Reteoo > Reporter: Mark Proctor > Assigned To: Mark Proctor > > There are times when you want to match facts by name, rather than by type+constraints. If we define a fact in an external process as > Cheese stilton = new Cheese(); > stilton.setType("stilton"); > workingMemory.assertObject(stilton); > The correct way to match this is object type match + field constraints: > stilton:Cheese(type == "stilton") > However there may be cases where you want to know that the bound variable stilton is bound to the same instance that the stilton variable references in the external application. This can be achieved via wrappers, similar to how primitive wrappers work: > Cheese stilton = new Cheese(); > stilton.setType("stilton"); > NamedFact stiltonNamedFact = new NamedFact("stilton", stilton); > drools.assertObject(stiltonNamedFact); > We can then have rules that do > NamedFact( type=="org.cheesery.Cheese", type == "stilton", stilton:value ) > This first constraints the rule to the correct NamedFact and then binds the wrapped value to the stilton declaration. This can be further improved with syntactic sure to automate the boxing and unboxing of the fact > drools.assertNamedObject("stilton", stilton); > And in the rule we do > rule "buy cheese" > var stilton; > when > ..... > then > end > or maybe vars could be defined in a parameter fashion > rule "buy cheese"(stilton) > when > ..... > then > end > Caveat: > This is generally a really bad idea and abused by people who still don't get the rule engine paradigm of pattern matching - and would use this though out their rule design. If you tie the matching process to named variables, extensively throughout, the engine becomes "hamstrung" and cannot optimise, turning Drools into nothing more than a BSF like scripting framework - its like buying a Ferrari to go to the local shops and back. It's also a "code smell" in that it breaks the declarative rule logic encapsulation paradigm in that the filtering/matching is tied to an external procoss - coupling the processes together. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBRULES-46) Backward Chaining

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-46?page=all ] Mark Proctor updated JBRULES-46: -------------------------------- Fix Version/s: (was: 3.1-m3) > Backward Chaining > ----------------- > > Key: JBRULES-46 > URL: http://jira.jboss.com/jira/browse/JBRULES-46 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assigned To: Mark Proctor > > Forward Chaining means that facts are asserted and propgated forward throughout the network, during forward propagation matching takes place which results in rules being fired - the rules are event based, in that they are fired in response to changed in the working memory. > Backward chaining is query based. Rules attempt to fire first but do not have the necessary matched facts, so facts are pulled in from an external source. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Deleted: (JBMESSAGING-512) Implement transparent failover

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-512?page=all ] Tim Fox deleted JBMESSAGING-512: -------------------------------- > Implement transparent failover > ------------------------------ > > Key: JBMESSAGING-512 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-512 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > > Implement transparent failover for jms clients as described in http://wiki.jboss.org/wiki/Wiki.jsp?page=NewClusteringDesign -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Deleted: (JBMESSAGING-513) Implement distributed destinations

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-513?page=all ] Tim Fox deleted JBMESSAGING-513: -------------------------------- > Implement distributed destinations > ---------------------------------- > > Key: JBMESSAGING-513 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-513 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > > Implement destributed queues and topics as described in http://wiki.jboss.org/wiki/Wiki.jsp?page=NewClusteringDesign -- 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, 11 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 August 2006