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

[Design of JBossCache] - Re: Last chance for any changes to the 2.0.0 API

by genman

"manik.surtani(a)jboss.com" wrote : anonymous wrote : | | Also, I'd like to hear some feedback on this issue: http://jira.jboss.com/jira/browse/JBCACHE-890 . I think we may want to add a couple of flags (three already come to mind.) Multiple booleans might be sufficient for the moment. Still, having a way to extend things cleanly might be nice in 2.0. | | | | Start a separate thread on this. I think that having such dynamically set series of flags on a node is a bit weird, wonder if we're better off with a limited set of getters/setters. I think a get/set(boolean) for the NodeSPI is fine. I'm more concerned about the underlying implementation: It's just likely that the set of properties of a node will expand over time. What will inevitably happen is you'll want to add more methods to NodeSPI. The idea is to add some potential for future expansion. If you think of the Tree as somewhat modeled off of a file system, the need for meta-data comes up time and time again. Maybe Java annotations can serve this role? But really you need something more dynamic. anonymous wrote : | Finally, from this hierarchy, I still don't see a clean way to access CacheSPI (or NodeSPI), except to do: | | CacheSPI spi = (CacheSPI)cache; | I "proposed" the API to access the node SPI should be Node.getNodeSPI(). This was cleaner rather than having to make an iffy cast all the time. I believe that a Cache.getCacheSPI() would be for the best. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994779#3994779 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994779

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Buddy replication cleanup in a transaction

by bstansberry＠jboss.com

I'm looking at DataGravitatorInterceptor.cleanBackupData (1.4 branch) and I think it's broken if there's a tx. If there's a tx, the RPC to cleanup data across the cluster is not made immediately, but rather is added to the tx modification list. That's good; we don't want to remove the data from other nodes unless the tx that caused the data gravitation commits. But, the modification list will get sent as part of a prepare() that will only go to the node's buddies, not to the whole cluster! So, the cleanup will not be cluster-wide, and quite likely will leave a second copy of the data lying around. I am missing something here? If not, I'll open a JIRA. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994764#3994764 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994764

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Injection Framework

by wolfc

Correct, the MC injection & dependencies are done in the setup phase. So for example if SessionBean1 wants SessionBean2 injected then SessionBean1 container is registered as being dependant on SessionBean2 container, which will start and put SessionBean2 in JNDI... MC starts SessionBean1 container, put SessionBean1 in JNDI, setup JNDI env (java:comp/env/SessionBean2 -> java:global.ear/SessionBean2/local) and then start the injection phase (java:comp/env/SessionBean2 -> SessionBean1.bean2Interface). To summarize scope: injection framework does (EJB3) bean injection, while the container (EJB2 + 3) work with MC for dependency injection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994753#3994753 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994753

19 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: OSGi integration

by alesj

"scott.stark(a)jboss.org" wrote : Being able to support osgi deployments is the only real plan. This meaning what - or how does this fit into framework vs. services picture? Or is this similiar to what Spring is doing with their OSGi support? Since I just had a discussion with Apache Felix (full OSGi implementation) lead and an OSGi EG lead about our integration. They are willing to help, but we need to know exactly what we want to do. Are we going to a full implementation (which is a lot of work for spec r4), or we can base our impl on top of Felix with appropriate hooks (where possible - but we could be able to contribute some code to Felix for this) or just a simple 'Spring like' implementation (depending on other full impls - Felix, Equinox, Knopflerfish, ...). How much work does our new Deployers architecture take away? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994752#3994752 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994752

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Injection Framework

by scott.stark＠jboss.org

Is there a question here or this is just the plan? As an integration piece, I would think we want an mc dependency injection handler so that an injection reference does result in a property dependency relationship. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994750#3994750 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994750

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Last chance for any changes to the 2.0.0 API

by ben.wang＠jboss.com

It is hard to say exactly what do I need from CacheSPI (or NodeSPI) now. When will you check in the new API or has it been updated in the Wiki? I have thought people who wants to customize the Cache behavior should use CacheSPI. Or has it been changed? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994718#3994718 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994718

19 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Change Process Definition!!

by zazichi

Has Anyone done something about process definition, in the way to divide the real process definition and the data displayed on the form that we can see when the workflow works on JBOSS? could anyone help me to find the way to do this division, if it is possible? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994712#3994712 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994712

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Last chance for any changes to the 2.0.0 API

by bstansberry＠jboss.com

Another thing I've thought about is renaming the TreeCache class to CacheImpl or something. We don't code to be written against the TreeCache class itself. There's a lot of legacy code written that way; changing the class name forces a shift to the new API. A kinder gentler way is to create CacheImpl, and then make TreeCache a trivial subclass. Then mark TreeCache deprecated with a comment it will be removed in 2.1 or 2.2. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994706#3994706 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994706

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Last chance for any changes to the 2.0.0 API

by bstansberry＠jboss.com

Re: exposing the TransactionManager, the http session repl code needs this. For http session repl, we use "BatchModeTransactionManager", not that main TM running in the AS. The external code to gets this from the cache, since it's the cache that creates the BatchModeTransactionManager. If we're exposing the TM directly via the Cache interface, I don't need that. Having the cache stick a ref to its TM in Configuration.runtime would serve the need. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994701#3994701 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994701

19 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: XORJoinNode

by yangdaolin

OK. I want to know how I make wiki page. thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994700#3994700 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994700

19 years, 3 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 December 2006