August 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Profiler] - Re: support plataform by JBoss

by mcavallera

"mcavallera" wrote : Hello, | | I have a doubt. | | Does the jBossProfiler run only on intel platform ? | | Is there any running version for: | | 1.Plataform:POWER5-->OS: Linux distribution SUSE | 2.Plataform: HP-->OS:HP-UX | | Regards, View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169686#4169686 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169686

17 years, 8 months

1
0
0 / 0

[Design of JBoss Profiler] - support plataform by JBoss

by mcavallera

Hello, I have a doubt. Does the jBossProfiler run only on intel platform ? Is there any running version for: POWER5/Linux distribuciÃÂ³n SUSE 2ÃÂ° HP/HP-UX Regards, View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169685#4169685 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169685

17 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-330 - Preconfigured MDR and scopes

by alesj

"adrian(a)jboss.org" wrote : | I've done that boss. ;-) | Nice work, my apprentice. :-) I only added a small change, by the API in AbstractScopeInfo::initMetaDataRetrieval, it's enough to get MetaDataRetrieval, no need for full MetaDataContext. So, I've changed the methods involved to return/use just MetaDataRetrieval. The actual impl will still be our AbstractMetaDataContext, but I'm always in favor for minimal interface when applicable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169676#4169676 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169676

17 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache 3.0 and JBoss AS 5

by bstansberry＠jboss.com

For ClusteredSSO, if we created an alternate impl of the web session SPI, any needed new ClusteredSSO impl would be packaged with it. It's only one class. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169671#4169671 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169671

17 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache 3.0 and JBoss AS 5

by bstansberry＠jboss.com

Two possible approaches: ASServiceA --> JBCIntgAPI --> JBCIntgImpl3 --> JBC 3 ASServiceB --> JBCIntgAPI --> JBCIntgImpl3 --> JBC 3 ASServiceC --> JBCIntgAPI --> JBCIntgImpl3 --> JBC 3 or ASServiceA --> ASServiceAJBCIntgAPI --> ASServiceAJBCIntgImpl3 --> JBC 3 ASServiceB --> ASServiceBJBCIntgAPI --> ASServiceBJBCIntgImpl3 --> JBC 3 ASServiceC --> ASServiceCJBCIntgAPI --> ASServiceCJBCIntgImpl3 --> JBC 3 I don't think I want to limit all AS usage of JBC to a single fixed API. I prefer to have the flexibility to use all features of a particular release for a particular service. There are 6 JBoss AS usages of JBC: 1) Hibernate 2LC. The 2nd style approach is already implemented: Hibernate --> RegionFactory --> cache-jbosscache2 --> JBC2 2) EJB3 SFSB. The 2nd style approach is already implemented in the next gen caching discussed at http://wiki.jboss.org/wiki/DevEJB3NewSFSBCache 3) Web sessions. JBC interaction already goes through a utility class; this needs conversion into a proper SPI, a factory for the implementation, and a separate jar for the implementation. Should be pretty simple, just needs doing. JIRA is https://jira.jboss.org/jira/browse/JBAS-5820 4) Clustered SSO. There already is an SPI and a mechanism for specifying the class of the impl. 5) DistributedState. I would prefer reverting DS to no longer use JBC over making any attempt to abstract out an SPI. TBH, I think this is a good idea anyway, just haven't done it due to other priorities. 6) HA-JNDI. Same as DistributedState. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169670#4169670 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169670

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService equiv to ServiceBindingManager

by bstansberry＠jboss.com

A question is what to do with the old org.jboss.system.ServiceBinding interface and it's usage in ServiceConfigurator (and OldServiceConfigurator): public interface ServiceBinding | { | /** | * Possibly override the configuration of a service. | * | * @param serviceName the JMX ObjectName of the service | * @exception Exception thrown on failure to override a configuration | */ | void applyServiceConfig(ObjectName serviceName) throws Exception; | } The new implementation has nothing to do with this. Possibilities: 1) Leave it there along with the old ServiceBindingManager code in case anyone was using it for something obscure that the new stuff couldn't handle. Minimize confusion for the 99.99% who don't fit this case by not providing the commented out mbean or the docs/examples/binding/sample-bindings.xml file. 2) Leave the interface there but drop the old implementation; if people want it they implement their own. This makes little sense to me. 3) Get rid of all of it. IMO #3 is the right way to go, but want to get comments before dumping the whole thing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169668#4169668 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169668

17 years, 8 months

1
0
0 / 0

[Design of JBossCache] - JBoss Cache 3.0 and JBoss AS 5

by manik.surtani＠jboss.com

Guys (particularly Brian and Paul, I guess) How could we easily write a delegation layer to make sure JBC 3 will work in AS 5? I'm sure folk in the community would be interested and if we can provide something that would be very valuable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169666#4169666 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169666

17 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Eviction redesign

by manik.surtani＠jboss.com

"bstansberry(a)jboss.com" wrote : My only other comment on this is to make sure a richly configured cache config can be built up using an IOC framework; i.e. not just by custom java code that knows the rules. And preferably without requiring a lot of advanced IOC usage to do it; just straight injection of pojos into a tree structure. I *think* what you are proposing does that, but it's lunch time, and I'm lazy, so I'm not sure. ;) I think it does that too. I guess lets get this into Beta1 and give it a whirl with JBoss MC, etc. and that will tell us for sure. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169665#4169665 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169665

17 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Eviction redesign

by manik.surtani＠jboss.com

"bstansberry(a)jboss.com" wrote : Hmm -- if I do this | | cache.put(Fqn.fromString("/a/really/deeply/nested/node", "key", "value") | | and all the higher level nodes already exist, are any eviction events generated for "/a", "/a/really", "/a/really/deeply", "/a/really/deeply/nested"? No. :-) There is merit to suppressing the construction of the EvictedEventNode if it is not needed though - perhaps Region.putNodeEvent() should look like: | Region.putNodeEvent(Fqn fqn, NodeEventType type, int elementDifference) | and the region can construct the EvictedEventNode if needed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169663#4169663 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169663

17 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Eviction redesign

by bstansberry＠jboss.com

"manik.surtani(a)jboss.com" wrote : Yup, see my comment above: | | "manik.surtani(a)jboss.com" wrote : | | ... | | * All other EvictionRegionConfigs will inherit values from EvictionConfig.getDefaultEvictionRegionConfig() for unset properties. This could be done by EvictionConfig when addEvictionRegionConfig() is called. | | ... | | Sounds good. My only other comment on this is to make sure a richly configured cache config can be built up using an IOC framework; i.e. not just by custom java code that knows the rules. And preferably without requiring a lot of advanced IOC usage to do it; just straight injection of pojos into a tree structure. I *think* what you are proposing does that, but it's lunch time, and I'm lazy, so I'm not sure. ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169662#4169662 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169662

17 years, 8 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 August 2008