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

[Design of EJB 3.0] - Updating InjectionHandler code

by scott.stark＠jboss.org

I updated the org.jboss.metadata.annotation.creator code in the metadata project to start dealing with javaee component resource group entries. So far only @EJB and @Resource annotations are being processed. The org.jboss.test.metadata.annotation.repository.MetaDataRepositoryUnitTestCase.testMemoryMetaDataLoader illustrates this for the MyStatelessBean test bean. @EJB maps to a new AnnotatedEJBReferenceMetaData type that will have to be mapped to either EjbReferenceMetaData or EjbLocalReferenceMetaData by the ReferenceMetaDataResolverDeployer when it determines what the target is. My question at this point is how to update the InjectionHandler impls to run of the resolved metadata view. I'm going to have a call with Carlo and Adrian to sync up on what I have, and discuss what needs to be done to finish the transition to the unified metadata. Either Carlo or myself will follow up here with that outcome. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102831#4102831 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102831

18 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - JBM 2 and test framework

by ataylor

The test framework needs re-writing for JBM2. The current is heavily reliant on using an mbean server and our current mbeans, obviously all this is changing and we wont need the current test service container. Currently we start the server and only stop and restart it when the configuration changes, this means that the tests do not run in isolation. This is obviously because it takes too long to restart it every time, the tests would take for ever to complete. Since we'll be able to bootstrap the server standalone the start up time will be much quicker, maybe we need to review how we run our test suite. Does anyone have any views? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102827#4102827 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102827

18 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ManagedObject support in next messaging release

by alesj

"scott.stark(a)jboss.org" wrote : Here is another approach that also moves toward having the annotations in the xml config. We do have some annotation support in the service mbean descriptors, for example: | I can see we are parsing the annotation element in mbeans. But we are not merging the annotations - as in MC - in some of the Controller actions? Is this something that should/must be done? Or is this the solution? :-) "scott.stark(a)jboss.org" wrote : | Possibly, if you change from -service.xml to -beans.xml for the destinations. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102809#4102809 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102809

18 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: New Build Artifact - EJB3 External API

by ALRubinger

"scott.stark(a)jboss.org" wrote : Referencing a cache configuration does not need a type-safe construct. That satisfies my concession A) :) "bstansberry(a)jboss.com" wrote : TBH, I don't see why @Cache needs to be in an ext-api jar at all Maybe, but it makes room for new Cache implementations we might derive in the future. And I'd like to keep the existing pattern where most metadata can be either XML- or annotation-based. If we don't need compile-time constraints on these annotations, I should be able to pull this together. Will update - thanks, all. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102765#4102765 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102765

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Leaking annotation API

by bstansberry＠jboss.com

"scott.stark(a)jboss.org" wrote : "bstansberry(a)jboss.com" wrote : | | Problem with this is the name of the annotation is @org.jboss.annotation.ejb.Clustered -- not a very generic name. | Yes, should just be recreated using a transport/remoting oriented package name. | Carlo, unless you're willing to break existing applications, this would mean ejb-core would need to support two annotations -- @org.jboss.annotation.ejb.Clustered and @org.jboss.ha.client.remoting.Clustered. The former would presumably be deprecated, and only exist in ejb-core.jar. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102761#4102761 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102761

18 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: New Build Artifact - EJB3 External API

by bstansberry＠jboss.com

TBH, I don't see why @Cache needs to be in an ext-api jar at all. It's a specification of what impl of an SPI to use, which is probably not the sort of thing we should be encouraging, and definitely isn't something that we need to make totally painless. The only reason a user would need to use this annotation is if they write a custom Cache impl. And if they do that they are going to have to have the full ejb-core jar on their classpath anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102756#4102756 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102756

18 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: New Build Artifact - EJB3 External API

by scott.stark＠jboss.org

Referencing a cache configuration does not need a type-safe construct. Its a lookup into a map, and its the bean providing that map that would enforce type safety using a Cache interface. There is no point to a @Cache annotation carrying implementation details. Nothing needs to implement the @Cache annotation in core, the Cache interface implementation is needed, and this is outside of an ejb provider class. The same applies to @Pool. Its a separate question as to whether you still want these type of annotations as part of the container implementation spi. I don't think they are that useful as its just as easy to configure aspects via xml. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102755#4102755 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102755

18 years, 5 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Bringing together an unified security view

by anil.saldhana＠jboss.com

The API is sufficient to hold CRUD type of access levels as long as you define the ACL permission class. But if projects start having complex requirements, then this jdk api may be insufficient. At this moment, I do not know. Maybe Scott can give better answer about the acl api in the JDK. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102752#4102752 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102752

18 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: New Build Artifact - EJB3 External API

by ALRubinger

The problem with extracting the external API into its own project is that we introduce cyclic compile dependencies all over the place: EJB3 Core Depends on ext-api, and it's very difficult to ensure that ext-api doesn't depend on Core without losing compile-time constraints. An example we've been discussing over the past couple weeks is @Cache, which historically took a value of a cache implementation, and now accepts a factory. But either way, eventually one of the classes in ext-api must extend from or implement Cache in core. One benefit of the monolithic layout to EJB3 in AS is that the entire source is available in one tree, compiled simultaneously, and we can pluck out individual classes and manually JAR them to make the ext-api. Proposed solutions using separate modules have included using a registered factory like: @CacheFactory(type="NoPassivationCache") ...where the "type" String is configured in an MC Bean and bound to an actual cache impl or factory. But here the bean provider loses compile-time constraints. So I'm going to draw up some rules. 1) Core depends on ext-api to compile 2) ext-api cannot depend on Core; must compile on its own Given both 1) and 2), something has to give, either: A) We ditch some compile-time constraints to get around the circular dependencies B) We keep ext-api as a build artifact in EJB3 Core, produced by the build script C) We undergo some surgery to clear up and redesign how @Cache and @Pool are used and try to separate out concerns in StatefulContainer and StatelessContainer Thoughts? I'm in circles. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102748#4102748 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102748

18 years, 5 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: 2.2.2-SP1.jar and 2.2.2-SP1-brew.jar different

by ron.sigal＠jboss.com

remoter here. I responded on the JBM forum. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102742#4102742 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102742

18 years, 5 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 November 2007