October 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - Re: CacheListener notifications during data gravitation

by bstansberry＠jboss.com

I think what Manik's suggesting isn't really LOCAL vs REMOTE but rather dataGravitation=true/false. It would get signalled on whatever node was affected by the gravitation. That could work, and is certainly less hacky than the ThreadLocal :) But, should this be added to all notifications? In my current usage of JBC, only confusion about the nodeRemoved caused a problem. But that's just because of the way the code works; other use cases may have a similar problem with other notifications. BTW, turns out this is not an issue for ClusteredSSO. Thinking about this made me realize BR is totally inappropriate for ClusteredSSO (I'd thought it was non-optimal but usable; it's not.) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975495#3975495 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975495

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: What's the status of HEAD?

by kabir.khan＠jboss.com

"vickyk" wrote : >>Where does MainWithSimpleHotDeployTestCase live? | You mean the working one, or the location where is this available? | I am not able to understand what you are asking | I meant where it was available, but I found it in TRUNK/system View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975491#3975491 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975491

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: What's the status of HEAD?

by vickyk

>>Where does MainWithSimpleHotDeployTestCase live? You mean the working one, or the location where is this available? I am not able to understand what you are asking View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975488#3975488 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975488

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: console layout

by tom.baeyens＠jboss.com

"david.lloyd(a)jboss.com" wrote : The thing that bothers me is that all the top level searches would then have a number of fields in common. | That is why i would put them on one page. On top you could have a radio button to specify what you're looking for: process definitions, process instances or tasks. Then depending on that choice, you could enable/disable certain parts of the form to enter search criteria. "david.lloyd(a)jboss.com" wrote : Also, I put Deploy Process Definition at the top level because there are no other management functions that I know of (you have ... after it) :-) | * (Re)binding process states to specific sub process definitions. * Checking the size of the logs * Migrating process instances or process definitions to another db * Avg tx time * ... Currently, there are not many implemented, but this should definitely grow, i think. Keep in mind that all of these should also be exposed via the JBoss operations network. "david.lloyd(a)jboss.com" wrote : Also, many of the stats queries depend on providing a process definition. So I thought it makes more sense, and would be simpler in any case, to provide these stats queries from a process definition page, where the user has already located the process definition and they want to find out more about it. You could have one search page as described above. You might for instance start from that page and get a list of process definitions. Then for each process definition there might be a link called 'search process instances'. When clicking that link, you could navigate to that same search screen with process instances already selected as the items to search for and also the selected process definition prefilled in the criteria. Is the idea clear ? I could sketch out something if that helps to get the picture. What do you think of the idea ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975487#3975487 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975487

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: What's the status of HEAD?

by adrian＠jboss.org

This test is broken. Things like | File resourcesDir = new File("output/eclipse-resources"); | deployPrefix = "tests/bootstrap/defaulthotdeploy/"; | should be replaced with something like: | URL rootOfMyTestResources = getResource("/tests/bootstrap"); | Also can we stop using the KernelRegistry.getEntry(); The correct api is KernelController.getInstalledContext(); (or getContext() if you are not sure it is fully installed). KernelRegistry.getEntry() will not pick up mbeans. They are only in the controller and the MBeanRegistry. I've got a good mind to deprecate that method, even though I've go intention of removing it. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975484#3975484 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975484

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: console layout

by david.lloyd＠jboss.com

The thing that bothers me is that all the top level searches would then have a number of fields in common. I figured that upon locating a specific process definition, for example, one might want to then search for only process instances that are related to that definition. The quick links thing grew out of an idea that the user could somehow add their own most common searches... but I'm not married to that idea. Also, I put Deploy Process Definition at the top level because there are no other management functions that I know of (you have ... after it) :-) Also, many of the stats queries depend on providing a process definition. So I thought it makes more sense, and would be simpler in any case, to provide these stats queries from a process definition page, where the user has already located the process definition and they want to find out more about it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975483#3975483 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975483

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: CacheListener notifications during data gravitation

by ben.wang＠jboss.com

I don't think the distinction of LOCAL vs. REMOTE will suffice though? I thought this is problematic for remote node as well. Maybe we should have a data gravitated event to distinguish this? But we still need to prevent the nodeRemoved event. So that may back to square one. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975478#3975478 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975478

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - console layout

by tom.baeyens＠jboss.com

i don't like the top level menu structure in http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsole * Quick Links * Deploy Process Definition * Find Process Definition i would prefer something like * Tasks (personal and group tasks) * Search (process executions, tasks, process definitions, ...) * Statistics (all stats queries) * Manage (deploy process definitions, ...) What do you think of this alternative ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975472#3975472 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975472

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: CacheListener notifications during data gravitation

by manik.surtani＠jboss.com

anonymous wrote : One solution I thought of was to have TreeCache set a boolean value in a ThreadLocal in _clusteredGet and _dataGravitationCleanup. A cache listener could then check for the ThreadLocal and ignore events that arise from data gravitation. Kinda hacky though. Should node removals originating from data gravitation cleanups emit notifications in the first place? I suppose so, for correctness and predictability of behaviour. What about an additional parameter to the remove notification, to indicate whether the remove is cluster-wide (i.e., a REAL remove) or local (i.e., a data gravitation cleanup)? This would be a 2.0.0 fix though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975471#3975471 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975471

19 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Code analyze

by adrian＠jboss.org

In general only make these changes if it improves the readability/maintainability of the code. e.g. removing dead/unnecessary code gives less to maintain in future. Removing temps doesn't change the semantics of the code so it doesn't really change anything. In some cases, temps are more optimal. e.g. code that doesn't use a temp that should: | doSomething(getSomethingLotsOfWork()); | doSomethingElse(getSomethingLotsOfWork()); | Also temps are useful for tracking down NPEs. | object.getSomething().getSomethingElse(); | should be | temp = object.getSomething(); | temp.getSomethingElse(); | So you know which part was null when you've only got the line number. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975464#3975464 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975464

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-dev-forums October 2006