July 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - Re: Too much jboss cache INFO logging

by david.lloyd＠jboss.com

It might be worth having a look at this: http://wiki.jboss.org/wiki/Wiki.jsp?page=LoggingStandards View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067926#4067926 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067926

15 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-181 & ManagedDeployments

by adrian＠jboss.org

"charles.crouch(a)jboss.com" wrote : | -1 | Tests for the management view of a component should be included in the testsuite and run as part of the build. The management view of a component should be considered as part of its public API. If it changes in an incompatible way, then tests should fail and dependent clients need to be updated. | | Thanks That policy (if I understand it correctly) will never scale and I won't subscribe to it. If such a policy were implemented developers would simply take the easy approach and never change the managed object view when their features evolve leaving the admin console and profile service both out-dated and potentially incorrect. It's hard enough getting people to keep dtds, schemas, WIKI/docs up-to-date. If they can't innvocate around the management views they provide they'll simply ignore it. However, at a different level I agree with you. Obviously the underlying metdata model should not change in an incompatible way otherwise profiles from one version won't load in a later version. Similarly it should be possible to take profiles edited in a later version and load them in earlier versions (provided the user has deliberately not used a feature from the later version). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067923#4067923 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067923

15 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Too much jboss cache INFO logging

by bstansberry＠jboss.com

:-) INFO is good only if it's quite likely to save a round trip back and forth with a customer on a support case to get config info. Of the 3 types of logging in Dimitris' snippet, the only one that comes up routinely is the version logging. That IMHO is OK at INFO, but really should just be a corporate policy thing -- i.e. if we decide across JBoss not to log versions at INFO, JBC shouldn't; if it's OK to do it at info, then JBC should, since it comes up so often. The "12:34:59,968 INFO [DefaultPartition-TomcatCache] Using marshaller org.jboss.cache.marshall.VersionAwareMarshaller" info can easily be deduced by looking at a config file. It's not something that comes up often either; maybe never. The interceptor chain factory stuff is harder; i.e. takes *some* effort to figure out the chain from a config file, and knowing the chain is important in some tricky cases. But, 90% of the benefit could be achieved just by adding a wiki page that shows what the chains look like in the standard setups: PESSIMISTIC, no cacheloader OPTIMISTIC, no cacheloader PESSIMISTIC, cacheloader w/ passivation=false OPTIMISTIC, cacheloader w/ passivation=false PESSIMISTIC, cacheloader w/ passivation=true OPTIMISTIC, cacheloader w/ passivation=true (Include DataGravitationInterceptor in all with a comment about how it's not there if buddy replication isn't enabled. Same for CacheMgmtInterceptor.) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067918#4067918 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067918

15 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Region management issues

by bstansberry＠jboss.com

Agreed that this is hacky, but either option is an implementation detail that can be changed. The hack should be simple and allows us to avoid adding a behavior change vs 1.x in 2.0. We can then look at non-hacky approaches at greater leisure. If we don't restore the 1.x behavior in 2.0, we really shouldn't restore it at all. Here's the hack impl. I haven't tried this; only quality guarantee I can give is that Eclipse doesn't give me any compile error warnings: | Index: RegionManager.java | =================================================================== | RCS file: /cvsroot/jboss/JBossCache/src/org/jboss/cache/RegionManager.java,v | retrieving revision 1.38 | diff -u -r1.38 RegionManager.java | --- RegionManager.java 28 Jun 2007 16:53:35 -0000 1.38 | +++ RegionManager.java 26 Jul 2007 16:08:42 -0000 | @@ -139,6 +139,8 @@ | { | Fqn fqnToUse = fqn; | if (DEFAULT_REGION.equals(fqnToUse)) fqnToUse = Fqn.ROOT; | + | + Region firstFound = null; | // first see if a region for this specific Fqn exists | if (regionsRegistry.containsKey(fqnToUse)) | { | @@ -152,6 +154,12 @@ | { | return r; | } | + | + if (type == Region.Type.MARSHALLING) | + { | + firstFound = r; | + } | + | } | | // if not, attempt to create one ... | @@ -195,11 +203,16 @@ | { | nextBestThing = r; | } | + | + if (type == Region.Type.MARSHALLING && firstFound == null) | + { | + firstFound = r; | + } | } | if (nextFqn.isRoot()) break; | } | | - return nextBestThing; | + return (nextBestThing == null ? firstFound : nextBestThing); | } | | /** View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067901#4067901 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067901

15 years, 8 months

1
0
0 / 0

[Design of JBoss Wiki] - Re: Portal 2.6 support...

by robdale

yay, it works on JBoss 4.2.1 + Portal 2.6.1 Thanks, Rob View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067892#4067892 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067892

15 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-181 & ManagedDeployments

by charles.crouch＠jboss.com

"scott.stark(a)jboss.org" wrote : | I see a view as a presentation option to the admin user. The purpose of the managed project is to expose the managed properties/ops for tools. Presenting those to the admin in a way they understand is the tools job. Even if we did provide hints for groupings, I still see the tools wanting to display these in their specific ways and as components have new managed features they will want to update their views. +1. There is no expectation that the UI of an admin console be dynamically rendered from metadata delivered by the management api. It is the responsibility of a console and its metadata to define how the data is ultimately presented. Support for versioning within a console could handle changes to the underlying management metadata. "adrian(a)jboss.org" wrote : | But doesn't that defeat the whole purpose of the Managed project? | | The admin console could do everything, but expecting it to keep in step | with changes is almost certainly a futile hope. | | Only if the admin console is able to react to new metadata (or old metadata | for that matter) will the project have any hope of staying relevant. | | The task is equivalent in scope/work to updating the doco everytime | somebody adds/changes configuration options. | In practice, if it is done at all, it is usually late and then misleading for users | of older versions. -1 Tests for the management view of a component should be included in the testsuite and run as part of the build. The management view of a component should be considered as part of its public API. If it changes in an incompatible way, then tests should fail and dependent clients need to be updated. Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067885#4067885 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067885

15 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-181 & ManagedDeployments

by adrian＠jboss.org

We'll have to agree to differ then. ;-) P.S. I was planning on writing my own Swing admin console that was entirely driven by the hints in the ManagedObjects. It might not be pretty, but it will test whether the information/model can be used to construct "reasonable" UI for user written deployers whose metadata model we know nothing about. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067884#4067884 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067884

15 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-181 & ManagedDeployments

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : "scott.stark(a)jboss.org" wrote : | | I agree with the notion of views, but this seems more of an admin tool task. | | But doesn't that defeat the whole purpose of the Managed project? | | The admin console could do everything, but expecting it to keep in step | with changes is almost certainly a futile hope. | | Only if the admin console is able to react to new metadata (or old metadata | for that matter) will the project have any hope of staying relevant. | | The task is equivalent in scope/work to updating the doco everytime | somebody adds/changes configuration options. | In practice, if it is done at all, it is usually late and then misleading for users | of older versions. I see a view as a presentation option to the admin user. The purpose of the managed project is to expose the managed properties/ops for tools. Presenting those to the admin in a way they understand is the tools job. Even if we did provide hints for groupings, I still see the tools wanting to display these in their specific ways and as components have new managed features they will want to update their views. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067876#4067876 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067876

15 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Region management issues

by galder.zamarreno＠jboss.com

+1 on nesting regions. If 1.x behaivour can be mantained, I'd go for it. anonymous wrote : You just change getRegion such that if Region.Type.MARSHALLING is passed, you keep a ref to the lowest region you find. You then keep looking for one with a classloader registered. If you find one with a classloader, return it. If not, return the first one you found. Looks a bit hacky, so i'd go for nesting regions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067871#4067871 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067871

15 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Deployer Sorting is still broken

by adrian＠jboss.org

I've added a test to the DeployerFlow test that shows the problem. I also changed the error message to make it less confusing. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067868#4067868 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067868

15 years, 8 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2007