June 2009 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Deployers Ordering Issue

by richard.opalka＠jboss.com

"alesj" wrote : "richard.opalka(a)jboss.com" wrote : | | No, deployment stage is something different, and imho it shouldn't have anything to do with explicit ordering. | | | What about this usecase? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240026#4240026 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240026

15 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Deployers Ordering Issue

by richard.opalka＠jboss.com

My idea how to fix it: ad1) Put all deployers to the same collection (not list per stage like current impl) ad2) on deployers chain retrieval * check whether sorting needs to be done (yes if deployers were added/removed to/from the chain from last getDeployersList() method call) * sort all deployers if change is detected only ad3) Return all deployers belonging to requested deployers chain (getDeployersList() method call) from sorted list of deployers NOTE: Sorting algorithm have to take deployment stages, inputs, outputs and relative order into account. Current algorithm based on comparing two deployers doesn't include all possible usecases and it ignores inputs and stages. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240024#4240024 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240024

15 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Deployers Ordering Issue

by alesj

"richard.opalka(a)jboss.com" wrote : | But new impl should take deployer stages into account, because domino sorting happens only on deployers on the same stage in current impl. No, deployment stage is something different, and imho it shouldn't have anything to do with explicit ordering. Like I said, the only logical thing for me is that dev phase check, everything else is just laziness --> more performance suffering boot time. ;-( View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240021#4240021 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240021

15 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Deployers Ordering Issue

by richard.opalka＠jboss.com

"alesj" wrote : | And you as well for not shutting my mouth on the first post. :-) Agreed "alesj" wrote : You should simply point this fact when I closed the issue, | since the rest of the discussion really went in all sorts of wrong directions. | Yes, it was really a long round, uuuf ;) "alesj" wrote : | The lazy was never meant as *you* being lazy, but in general. (hope you didn't take it personally ;-)) | Specially with checking the existing deployers, which is very simple to do with statistics. I knew it's just a phrase. "alesj" wrote : | I'll now try to get to the bottom of the *real* issue. :-) IMHO it's the fact you're not validating the inputs (as mentioned so many times). But new impl should take deployer stages into account, because domino sorting happens only on deployers on the same stage in current impl. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240020#4240020 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240020

15 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Journal Cleanup and Journal Compactor

by timfox

"clebert.suconic(a)jboss.com" wrote : | | The problem is, when deleteing or updating a record, I don't know where the AddRecord is going to be located at. So, I don't know where to add the negative value to. | | So, what I'm thinking as a solution is: | | - During compacting, all Adds, updates and deletes are stored to the current-file, as we aways do. | | - But instead of discounting POSFiles right away, I cache those IDs on a collection. When I'm done compacting I do a fast operation applying the reference counts accordingly. | | - Case the server is interrupted during reload, the delete or update will take the original location of the record. | Isn't it simpler than this? When compacting you don't touch the information in memory. So if an update or delete comes in you just update as normal. Then when the compacting is done you just do a quick switch over in memory. I don't see why you need to cache anything. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240019#4240019 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240019

15 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MC tools

by alesj

I moved the existing code to a sub-project of mc-tools, so that we can have multiple tools under separate release lifecycle. New location: - http://anonsvn.jboss.org/repos/jbossas/projects/mc-tools/smd2bmd/trunk/ View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240018#4240018 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240018

15 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Deployers Ordering Issue

by alesj

"richard.opalka(a)jboss.com" wrote : | Nothing special, I'm just trying to access "DeploymentType" in deployer3 and deployer4, | because only deploye2 is providing this output.? | Ah, it's me then that's being lazy/blind. :-( And you as well for not shutting my mouth on the first post. :-) You should simply point this fact when I closed the issue, since the rest of the discussion really went in all sorts of wrong directions. "richard.opalka(a)jboss.com" wrote : | Do you still think I'm really so lazy? The lazy was never meant as *you* being lazy, but in general. (hope you didn't take it personally ;-)) Specially with checking the existing deployers, which is very simple to do with statistics. I'll now try to get to the bottom of the *real* issue. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240016#4240016 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240016

15 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Deployers Ordering Issue

by richard.opalka＠jboss.com

"alesj" wrote : "richard.opalka(a)jboss.com" wrote : | | Then tell me what's wrong with this? Where's the lack of info I didn't provide? | Dunno, it depends on what you're doing in those 3 deployers. | Nothing special, I'm just trying to access "DeploymentType" in deployer3 and deployer4, because only deploye2 is providing this output.? Do you still think I'm really so lazy? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240011#4240011 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240011

15 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Deployers Ordering Issue

by alesj

"richard.opalka(a)jboss.com" wrote : | Then tell me what's wrong with this? Where's the lack of info I didn't provide? Dunno, it depends on what you're doing in those 3 deployers. They all input JBWD and output JBWMD, which is completely valid, if they don't interfere with each others JBWMD usage/setup/config. But if they do, I very much doubt that there exist a simple (read fast and declarative) algorithm that would order you that. ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240009#4240009 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240009

15 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Deployers Ordering Issue

by richard.opalka＠jboss.com

"alesj" wrote : "richard.opalka(a)jboss.com" wrote : | | Rule no. 1: Always implement comparable if your object instances represents natural order. | | | There is a better rule. | Only implement what you actually need. | There is no need to really compare stages, at least not atm. | Agreed "alesj" wrote : | But you could do it this way: | ControllerStateModel model = ...; | DeploymentStage ds1 = ...; | ControllerState cs1 = new ControllerState(ds1.getString()); | DeploymentStage ds2 = ...; | ControllerState cs2 = new ControllerState(ds1.getString()); | boolean isBefore = model.isBefore(cs1, cs2); | IMHO ds1.compareTo(ds2) its more intuitive. Your solution includes whole MC knowledge people usually don't have ;) "alesj" wrote : | But if I in both cases need A and output A, B, | where in 1st deployer I set A.someprop | but in 2nd deployer I use that A.someprop, | all I need to do is express this via proper input/output, | e.g. D1.output=A.someprop, D2.input=A.someprop Then tell me what's wrong with this? Where's the lack of info I didn't provide? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240006#4240006 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240006

15 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2009