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

[Design of POJO Server] - Re: Moving forward with the profile service mgmt api

by scott.stark＠jboss.org

Its something I'm looking at. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995407#3995407 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995407

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: java:comp.ejb3 versus java:comp

by scott.stark＠jboss.org

In terms of an aspect, why shouldn't pojos, mbeans, etc.? The issue is that even with ejbs, wars, there are background container initiated invocations that today should have a class loader that ties to the old enc map, now need to have access to the key that identifies their enc. Not every container is going to be rewritten to use the aop invocation model. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995400#3995400 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995400

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: java:comp.ejb3 versus java:comp

by bill.burke＠jboss.com

what else has an ENC besides a WAR and an EJB? EJB3 creates its own ENC and pushes/pops it onto a ThreadLocalStack that the ObjectFactory uses. Why can't a WAR do the same exact thing? Does JBossWeb control ENC creation or does Tomcat specific libraries? If JBossWeb, then it should be easy to add something to push/pop a JBossWeb created ENC and share the ObjectFactory implementation EJB3 uses. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995396#3995396 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995396

19 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: java:comp.ejb3 versus java:comp

by scott.stark＠jboss.org

The class loader based ENCFactory really should be dropped for a thread or invocation context keyed implementation. The main issue in switching is getting all of the component calls paths tied into the correct lookup mechanism. We also need a jndi Context wrapper that allows the enc context to be read-only. This should be a common ENCMap bean that provides the various enc Contexts keyed by a unique component deployment id. The id key is what needs to be made available for the java:comp ObjectFactory via thread local or invocation context key. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995392#3995392 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995392

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

"manik.surtani(a)jboss.com" wrote : | "bstansberry(a)jboss.com" wrote : | | 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. | | Do we really want this? Like you said we don't want people talking to the implementation directly at all, especially since we can't guarantee correct behaviour with the interceptor chains, etc. I'd rather remove this altogether, like you said forcing people to write to the new API. +1 from me on not doing that. I added the idea in case any 'kinder, gentler' readers were concerned about changing the name. I'm a heartless thug. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995387#3995387 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995387

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

"manik.surtani(a)jboss.com" wrote : "bstansberry(a)jboss.com" wrote : | | 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. | | Don't we expose this via the runtime right now? Yeah, we do. I expressed that badly. Also I double checked -- if the cache uses the TMLookup to find the TM, it then adds the TM to the runtime. So it's always available that way. So no reason to expose it via the Cache interface. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995386#3995386 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995386

19 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: JTA integration

by gavin.king＠jboss.com

Or are you saying that you are using getCurrentSession() of the SF that you create internally. Ah, well, thats fine. But one of these days I would really like to be able to have a single persistence context for user entities and jBPM entities. Well, I guess its not as critical for now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995375#3995375 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995375

19 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: JTA integration

by gavin.king＠jboss.com

This is useful, I suppose, but is not really enough for Seam, since Seam is not using the "current" Hibernate session. What I really want to be able to do is pass a sesison to the method that creates a jbpm context. Yes, I also need the behavior that jBPM does not flush or close the session, or commit the transaction. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995368#3995368 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995368

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Serialization Compatibility Tests

by pavel.tsekov＠redhat.com

| <object class="org.jboss.tools.ClassVersionInfo"> | <void property="name"> | <string>org.jboss.aop.pointcut.ast.ParseException</string> | </void> | <void property="serialVersion"> | <long>6640507307072022813</long> | </void> | </object> | Thanks, for the hint! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995364#3995364 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995364

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: JBCACHE-890 - idea for consolidating meta-data on a node

by manik.surtani＠jboss.com

On an implementation level, this makes sense. But on an interface level, I prefer individual getters/setters. I see your point mentioned on a different thread: "genman" wrote : | | 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. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995358#3995358 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995358

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