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

[Design of EJB 3.0] - Re: EJBTHREE-1167 -- Resolve API leak for @Clustered

by ALRubinger

"bstansberry(a)jboss.com" wrote : So, I don't mind the annotation moving into ejb3-ext-api. Sweet. I'll do that, then, and resolve the dependencies on LoadBalancePolicy via a String-based configuration. "bstansberry(a)jboss.com" wrote : If the goal is just to have no dependency from ejb3-ext-api and ejb3-impl to ha-client, it's not necessary. | | BTW, the above statement is based on my very vague understanding of the purpose of ejb3-impl vs. ejb3-core. If what I said makes no sense, please tell me. Nope, that's all in line. The purpose of these projects is also being defined by us as we go... :) ejb3-ext-api: EJB3 Bean Provider API of JBoss-specific extensions ejb3-impl: Implementations (internals) conforming to ext-api ejb3-core: Currently under restructuring; the projectized view of the current AS EJB3 Module. Internals without an API; glue that ties together the other components (cache, pool, etc). Only pending issue: If I steal out @Clustered from ha-client now and commit, that'll go to the next snapshot and not affect the release you'd made for Beta3, right? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114400#4114400 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114400

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1167 -- Resolve API leak for @Clustered

by bstansberry＠jboss.com

anonymous wrote : You beat me to this before I could ping you on it :) By luck the JIRA message was prominent in my morning e-mail pile, so you got a response before the deluge buried me. :-) anonymous wrote : | Yep. Though a couple months back we determined that @Clustered was not specific to EJB3, so we put it into HA. I'd originally put ClusteredImpl in there as well, but took it back when you'd asked. Yeah, but then Adrian kindly discovered EJBTHREE-1109. ;-) Which led to EJBTHREE-1110 (add a home load balance policy attribute), and with that the annotation is pretty EJB3 specific. So, I don't mind the annotation moving into ejb3-ext-api. anonymous wrote : | bstansberry(a)jboss.com wrote : Before going down this road though, we should determine how to handle the aspects module, which also depends on the ha-client project. | | That necessary, or your preference? :) | Hadn't drunk enough coffee; wasn't thinking clearly. If the goal is just to have no dependency from ejb3-ext-api and ejb3-impl to ha-client, it's not necessary. The aspects module classes have a dependency on ha-client, and that would "leak" back into ejb3-core. But ejb3-core is probably going to have the ha-client dependency anyway, via the clustered proxies. BTW, the above statement is based on my very vague understanding of the purpose of ejb3-impl vs. ejb3-core. If what I said makes no sense, please tell me. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114397#4114397 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114397

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileServiceUnitTestCase value/type misuse

by scott.stark＠jboss.org

There was the question of primative types vs SimpleMetaType and whether the ManagedProperty should be accepting primatives and autoboxing these into SimpleValues. I think we should look into doing this. The question also came up of enforcing a check against the ManagedProperty.getMetaType().isValue(Object) for the values passed into ManagedProperty.setValue(Object). Could be done with aop, but I don't think we can assume jboss aop is available/used in the admin client. It could also be done via a wrapping proxy that imposed this behavior, as well as the autoboxing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114392#4114392 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114392

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - ProfileServiceUnitTestCase value/type misuse

by scott.stark＠jboss.org

There are still some bad uses of deployment specific types in the ProfileServiceUnitTestCase tests. We are using mcf metadata types like ManagedConnectionFactoryPropertyMetaData, XAConnectionPropertyMetaData. These need to be converted into CollectionMetaType("java.lang.String", SimpleMetaType.STRING) types. Note that we are also leaking the attachment types as a classpath dependency because the ManagedObject references the deployment attachment. This should not be part of the serialization contract. We need to get the console work going forward to really drive the management implementation to completion in my view. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114389#4114389 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114389

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1167 -- Resolve API leak for @Clustered

by ALRubinger

You beat me to this before I could ping you on it :) bstansberry(a)jboss.com wrote : As long as @Clustered itself is in ha-client, ClusteredImpl depends on ha-client. So I don't see the benefit of replacing the class with a string. And if ClusteredImpl (to be moved to ejb3-impl) depends on ha-client, ejb3-impl will depend on ha-client. I'd like to avoid this. bstansberry(a)jboss.com wrote : I suppose if you changed it to a string *and* took the annotation itself back into ejb3, then you get a benefit. Yep. Though a couple months back we determined that @Clustered was not specific to EJB3, so we put it into HA. I'd originally put ClusteredImpl in there as well, but took it back when you'd asked. So I see a couple solutions: 1) Move @Clustered to ejb3-ext-api, ClusteredImpl to ejb3-impl, and make Strings out of the load balance configuration. This makes @Clustered EJB3-specific. 2) Put ClusteredImpl back into HA somewhere, with dependency on ha-client to fulfill the reference to LoadBalancePolicy. EJB3 is the only project using this class, but then there'd be no API leak. bstansberry(a)jboss.com wrote : Before going down this road though, we should determine how to handle the aspects module, which also depends on the ha-client project. That necessary, or your preference? :) Thx. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114382#4114382 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114382

16 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - WS-RM Prototype Ready for Preview

by richard.opalka＠jboss.com

Hi Team/Community, WS-RM Prototype is ready and available for preview. The WS-RM test suite is executed against real endpoints and combinations with WS-Security are covered as well. For documentation take a look here: http://jbws.dyndns.org/mediawiki/index.php?title=WS_Reliable_Messaging To execute the test suite, just type: ./build.sh -Dtest=jaxws/wsrm test on commandline. Please review the tests provided in the test suite and provide your feedback, comments, criticism to this forum. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114305#4114305 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114305

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: metadata

by bdecoste

I did - I removed the embedded tests in projects/ejb3. That was the only dependency on jbossas that I encountered. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114282#4114282 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114282

16 years, 5 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - 3.0.0-M1 tagged

by david.lloyd＠jboss.com

I've tagged 3.0.0-M1. This is essentially an alpha version of Remoting 3. The main features that distinguish this version from what come before are: * It compiles * It can connect via JRPP and local protocols * Simple invocations work (no streaming yet) This is a great point for others to get involved - check out the code base, try building it, try making it do stuff. Open bugs in JIRA, and let your opinions be known on this forum. In return, I promise not to break the build anymore after this release. I'll give you one hint to get started - you need to create an Endpoint using Remoting.createEndpoint(). For the rest - good luck! :-) (Did I mention that we need a user manual?) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114239#4114239 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114239

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - EJBTHREE-1167 -- Resolve API leak for @Clustered

by bstansberry＠jboss.com

To clarify the problem description from http://jira.jboss.com/jira/browse/EJBTHREE-1167 @Clustered (in the ha-client project) has a reference to org.jboss.ha.client.loadbalance.LoadBalancePolicy (also in the ha-client project). There are no references back to the cluster module in JBoss AS. As long as @Clustered itself is in ha-client, ClusteredImpl depends on ha-client. So I don't see the benefit of replacing the class with a string. I suppose if you changed it to a string *and* took the annotation itself back into ejb3, then you get a benefit. Before going down this road though, we should determine how to handle the aspects module, which also depends on the ha-client project. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=124773, particularly the last post. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114226#4114226 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114226

16 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: New state transfer in JBoss Cache

by manik.surtani＠jboss.com

I see what you mean. Perhaps some optimisation could be done on the queue before it is replayed? E.g., pull out all PREPAREs and corresponding ROLLBACKs, so you are now left with PREPARE and COMMIT combinations that you know should work as they have been applied on other nodes. Then make sure they are contiguous so that a PREPARE is followed immediately by it's corresponding COMMIT. Would this have any ordering issues? I guess with P/L perhaps not since the prepare would logically hold locks until the commit runs so the PREPAREs would dictate order. With O/L the result of a later commit would be a rollback which would be weeded out of the queue by this stage. And with MVCC writes will behave a bit like P/L so I guess we are ok here. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114192#4114192 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114192

16 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums December 2007