Re: @Proxy

2012-09-13 Thread Stuart Douglas 



Romain Manni-Bucau wrote:

right

the question here is do we want to use it or not internally (cdi-query was
based on it no? and i think it avoid to repeat too much code, we could
handle the annotation indirection you speak about to be clearer in APIs)

if we dont' want to use it, it can wait CDI-110 otherwise we can push it
now (maybe take servicehandler code but removing javassist?)


Javassist was only used so that we could support abstract classes as 
well. I think this is a useful feature, but I agree that the javassist 
dependency is problematic.


Something that has been on my list to do for quite a while is write a 
single class ProxyFactory with no outside dependencies, that can just be 
copied or shaded into whatever project needs it.


Stuart




i'm still not very clear about DS and its CDI targets: saw CDI 1.0 is a
target so maybe we should address it even if CDI 1.1 answer later to this
question...i'm not very concerned about it but it should be taken into
account i think

*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*




2012/9/14 Stuart Douglassdoug...@redhat.com


I suppose it depends on if 
https://issues.jboss.org/**browse/CDI-110https://issues.jboss.org/browse/CDI-110makes
 it into the specification.

This sounds equivalent to the solder @ServiceHandler annotation, although
@ServiceHandler has another layer of indirection, so you do not need to
specify the implementation class directly on the bean.

I think this is a useful feature.

Stuart


Romain Manni-Bucau wrote:


Hi,

wonder if we want the already bridged proxy feature (i'll explain don't
worry ;)).

There are cases where the implementation is boring and pretty obvious and
defining an interface has the benefit to creates a semantic but the
implementation itself is pretty useless (ex: spring-data, cdi-query, ...)

We can of course do as usually and create proxy for all features needing
it specifically.

However i think this proxy feature is generic enough and could be pushed
to
the user if he wants to do so.

Here some functional cases i think about which could use this feature:
1) (already cited) a cdi-query like
2) accessing JMX information (locally or not) without needed to use JMX
API
(
http://svn.apache.org/repos/**asf/openejb/trunk/openejb/**
examples/dynamic-proxy-to-**access-mbean/src/test/java/**
org/superbiz/dynamic/mbean/**DynamicMBeanClient.javahttp://svn.apache.org/repos/asf/openejb/trunk/openejb/examples/dynamic-proxy-to-access-mbean/src/test/java/org/superbiz/dynamic/mbean/DynamicMBeanClient.java
for
instance)
3) creating a rest api easily from method name (getUserList -   GET
/user/list for instance)
4) 

it can go further allowing multiple handlers by interface

wdyt?

*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.**comhttp://rmannibucau.wordpress.com
*

Re: XML Config

2012-09-10 Thread Stuart Douglas 



   	   
   	Mark Struberg  
  11 September 2012
 1:59 AM
  
One of the credos is that you MUST NOT repackage for just 
moving to a new server.Either this is in JNDI (same location) or 
just use @Inject ProjectStage ps; to check on which server you are 
running. I see no benefit of moving config to XML if it's not 
picked up from a really changable location.
  

I kinda agree with this, and in AS7 upstream you can now use deployment 
overlays to modify an individual descriptor without having to open up 
the archive (I am pretty sure some other servers also support this). I 
think
we should also support reading the external config (wether XML or not) 
from an outside location somehow. Just using the ProjectStage is not 
really sufficient for all use cases IMHO, as you may have multiple 
production servers with different configurations.  


  
To me this just means to replace hardcoding in java sources 
with hardcoding in some XML which gots scanned by java sources.

  

Personally I think there are quite a few advantages of configuring via 
XML: 

- It is obvious to new developers where your configuration settings are 
(META-INF or WEB-INF)
- You can inspect any pre-built archive and see what settings are in 
effect
- You can also potentially modify those settings with just zip and a 
text editor (I know this is not ideal, but if your fighting fires and 
just need to get your app back online this is a lot better than having 
to do a full re-build).
- Servers that support modification of descriptors at deployment time 
can modify the config
- There are lots of editors with XML support
- There are lots of developers that know XML

I really don't think that hard coding configuration via annotations is a
 good idea. Configuration should be plain text, and I think a lot of the
 push back against XML is more because of the Spring/J2EE overuse of it 
in the past has made a lot of developers hate XML. 

Stuart

  
LieGruestrub- Original Message 
-
  
   	   
   	Bernard Łabno  
  11 September 2012
 1:41 AM
  Ok, what If I have library
 with CDI beans that send emails and need to haveJNDI of mail 
session configured?When I attach this library to project A that is 
deployed on JBoss AS7 itmay have different jndi then in some other 
project or server.2012/9/10 Marius Bogoevici 
marius.bogoev...@gmail.com
   	   
   	Marius Bogoevici  
  11 September 2012
 12:20 AM
  Spring supports it, but in 
practice you'd want to stay away from it. I 
thought more along the lines of a script that is interpreted at startup.



   	   
   	Mark Struberg  
  11 September 2012
 12:15 AM
  hmm 'scriptable' imo 
implies that it can be changed at runtime. But that's by design not 
possible with CDI. Spring supports this, we do not. Otoh this allows us 
to be much faster in all 'static' use cases.LieGrue,strub-
 Original Message -
   	   
   	Marius Bogoevici  
  10 September 2012
 11:20 PM
  Generally speaking, I think it 
would be good to have a mechanism for 
configuring beans that does not require re-compilation - may be of 
limited use in greenfield applications, but above all with 
brownfield/legacy code. In fairness, for the latter one could use 
producers and such, but it may still be a PITA in some cases.

Now, the key here IMO would be to have a scriptable (no 
recompilation) 
and toolable DSL outside the annotation system. It so happens that of 
all the options, XML is IMO the most common and better understood by the
 
average developer. If we manage to define a proper intermediate model 
for this mechanism, then there could be plenty of other options (yaml, 
or even Groovy or Ruby if one so wishes) to add on later.

Re: RequestScoped entityManager

2012-08-26 Thread Stuart Douglas 

On 24/08/2012, at 7:47 PM, Mark Struberg strub...@yahoo.de wrote:

 Well, we might miss some explanation for this lines
 
 
   @PersistenceContext(unitName=default)
 private EntityManager entityManager;
 This only works in SE. In an EE container you will get a Container Managed 
 EM, which is not manageable by the user, but strictly bound to EJBs.
 
 Even the sample of softwaremill will not work on every EE container
 
@PersistenceUnit(name=pu)
private EntityManagerFactory emf;
 
 On a few servers the EE - injected EMF will only allow you to create managed 
 EMs.
 

This is a complete violation of the JPA spec, which containers do this? 

Stuart


 The best approach is to either create an additional 
 EntityManagerFactoryProducer where you can even stuff in JPA properties in a 
 central place, and inject it via CDI:
 
@Inject
private EntityManagerFactory emf;
 Or you can simply do:
 
 @ApplicationScoped // important!
 public class EntityManagerProducer {
private EntityManagerFactory emf = 
 Persistence.createEntityManagerFactory();
 
 @Produces @RequestScoped
 public EntityManager getEntityManager() {
 return new EntityManagerTxEnlistDecorator 
 (emf.createEntityManager());
 }
 
 public void close(@Disposes EntityManager em) {
 em.close();
 }
 }
 
 
 Please note that this is the classic way to get a non-JTA EM! If you like to 
 use UserTransactions, then check our JPA module. Guess Gerhard added a sample 
 for it.
 
 LieGrue,
 strub
 
 
 
 
 - Original Message -
 From: Adrian Gonzalez adr_gonza...@yahoo.fr
 To: deltaspike-dev@incubator.apache.org 
 deltaspike-dev@incubator.apache.org
 Cc: 
 Sent: Friday, August 24, 2012 11:38 AM
 Subject: RequestScoped entityManager
 
 Hello,
 
 Does DS provides a requestScopes em ?
 
 I tried to to something like https://cwiki.apache.org/EXTCDI/jpa-usage.html, 
 but 
 I had an error (don't remember which one, I think it was because em 
 wasn't associated with current tx)
 
 For the moment, I'm using softwaremill EntityManagerTxEnlistDecorator 
 (https://github.com/softwaremill/softwaremill-common/tree/master/softwaremill-cdi/src/main/java/pl/softwaremill/common/cdi/persistence
 and doing something like (I'm doing it from memory so, there can be some 
 errors) :
 
 public class EntityManagerProducer {
@PersistenceUnit(name=pu)
private EntityManagerFactory emf;
 
 @Produces @RequestScoped
 public EntityManager getEntityManager() {
 return new EntityManagerTxEnlistDecorator 
 (emf.createEntityManager());
 }
 
 public void close(@Disposes EntityManager em) {
 em.close();
 }
 }
 
 Not sure if it deserves a special classe in DS (perhaps at least 
 softwaremill EntityManagerTxEnlistDecorator   ?)
 
 Thanks

Re: CDI EG requires feedback

2012-08-15 Thread Stuart Douglas 

On 15/08/2012, at 11:20 PM, Pete Muir pm...@redhat.com wrote:

 All, the CDI EG requires feedback on an item in the spec which is not clear, 
 and has been implemented differently between implementations, and is not TCK 
 tested. As Deltaspike contains lots of extensions authors, requesting 
 feedback. Please either send direct to me, or post to cdi-...@lists.jboss.org 
 :-)
 
 
 
 Multiple Annotated Types
 
 
 https://issues.jboss.org/browse/CDI-58
 
 This concerns whether there can be greater than one annotated type per class 
 instance in the JVM. Gavin intended there should be, principally to support 
 an XML configuration dialect, which could introduce multiple versions of a 
 class, each with a different qualifier. However, this is not TCK tested, and 
 implementations vary in how they support this. 
 
 We discussed that this makes an implementation considerably more complex (as 
 there is no easy way to uniquely identify an annotated type e.g. for 
 serialization), and also is pretty confusing for a user (as you now get 
 multiple ProcessAnnotatedType events for each class, making it hard to know 
 which one you want to change).
 
 We looked at alternative solutions, and concluded that if all use cases can 
 be satisfied by adding a new bean, rather than a new annotated type, we would 
 like to explicitly specify that there is only one annotated type per class 
 instance. In CDI 1.1 it is already much easier to add and manipulate beans 
 from annotated types, so we believe that the correct thing here is take this 
 route.
 


I think there are some issues here. In order to get consistent behaviour the 
XML extension relied upon PAT being fired for every class it defined, so other 
extension could then modify the annotated type in a consistent manner.

Later on Weld changed its behaviour so that PAT was not fired when annotated 
types were added through the SPI, in order to work around this I made the XML 
extension fire PAT for these type itself in order to provide backwards 
compatibility, which is a horrible hack that is now causing problems for Delta 
Spike. 

If we make this change to the specification I don't think that it will be 
possible to implement a viable XML extension. 

I am aware that this present challenges for serialisation and clustering, 
however I worked around this in Weld when I was writing the XML extension by 
creating a class that creates a deterministic bean id based on the annotations 
on the class 
(https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/util/AnnotatedTypes.java#L185),
 I wrote this code before I was working for Red Hat an I am quite happy to 
license it under Apache or any other license. 
 
Stuart


 
 
 Does anyone create multiple AnnotatedTypes per class instance? If so, can you 
 please describe:
 
 a) why you need to do this
 b) whether you could reimplement by directly creating beans (given that CDI 
 1.1 allows you to [1])
 c) how much effort it would be to reimplement/how much of your codebase this 
 would affect
 
 Thanks!
 
 Pete
 
 [1]
 
 BeanAttributes ba = beanManager.cerateBeanAttributes(annotatedType);
 InjectionTarget it = beanmanager.createInjectionTarget(annotatedType);
 Bean b = beanManager.createBean(ba, clazz, it);
 
 or
 
 BeanAttributes ba = beanManager.cerateBeanAttributes(annotatedFieldOrMethod);
 Producer p = beanmanager.createProducer(annotatedFieldOrMethod);
 Bean b = beanManager.createBean(ba, clazz, p);
 
 The Bean can then be registered using 
 
 afterBeanDiscovery.addBean(b);

Re: CDI EG requires feedback

2012-08-15 Thread Stuart Douglas 

On 16/08/2012, at 12:41 AM, Pete Muir pm...@redhat.com wrote:

 
 On 15 Aug 2012, at 15:30, Stuart Douglas wrote:
 
 
 On 15/08/2012, at 11:20 PM, Pete Muir pm...@redhat.com wrote:
 
 All, the CDI EG requires feedback on an item in the spec which is not 
 clear, and has been implemented differently between implementations, and is 
 not TCK tested. As Deltaspike contains lots of extensions authors, 
 requesting feedback. Please either send direct to me, or post to 
 cdi-...@lists.jboss.org :-)
 
 
 
 Multiple Annotated Types
 
 
 https://issues.jboss.org/browse/CDI-58
 
 This concerns whether there can be greater than one annotated type per 
 class instance in the JVM. Gavin intended there should be, principally to 
 support an XML configuration dialect, which could introduce multiple 
 versions of a class, each with a different qualifier. However, this is not 
 TCK tested, and implementations vary in how they support this. 
 
 We discussed that this makes an implementation considerably more complex 
 (as there is no easy way to uniquely identify an annotated type e.g. for 
 serialization), and also is pretty confusing for a user (as you now get 
 multiple ProcessAnnotatedType events for each class, making it hard to know 
 which one you want to change).
 
 We looked at alternative solutions, and concluded that if all use cases can 
 be satisfied by adding a new bean, rather than a new annotated type, we 
 would like to explicitly specify that there is only one annotated type per 
 class instance. In CDI 1.1 it is already much easier to add and manipulate 
 beans from annotated types, so we believe that the correct thing here is 
 take this route.
 
 
 
 I think there are some issues here. In order to get consistent behaviour the 
 XML extension relied upon PAT being fired for every class it defined, so 
 other extension could then modify the annotated type in a consistent manner.
 
 IOW this would prevent XML defined class from then being modified by another 
 extension.

Yes, which is very non-intutive considering the way the existing XML syntax. I 
know is is not a standard, but it has seen wide adoption, and people expect 
that applying an annotation via XML is the same as applying it to the class 
itself.  

 
 
 Later on Weld changed its behaviour so that PAT was not fired when annotated 
 types were added through the SPI, in order to work around this I made the 
 XML extension fire PAT for these type itself in order to provide backwards 
 compatibility, which is a horrible hack that is now causing problems for 
 Delta Spike. 
 
 If we make this change to the specification I don't think that it will be 
 possible to implement a viable XML extension. 
 
 The XML would work but couldn't have it's behaviour changed by other 
 extensions.

Kind of, but it also becomes a lot more complex to implement, you definitely 
could not just take the old Seam XML extension and expect it to work. there is 
not a 1:1 relationship between beans and annotated types, because annotated 
types can have producer methods. 

I think that this is actually a feature, and a feature that Seam XML relied on. 
If this becomes spec I think that a lot of legacy apps will stop working. 
Sometimes breaking backwards compatibility is necessary, but in this case I 
don't really see any advantage too it. 


 
 
 I am aware that this present challenges for serialisation and clustering, 
 however I worked around this in Weld when I was writing the XML extension by 
 creating a class that creates a deterministic bean id based on the 
 annotations on the class 
 (https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/util/AnnotatedTypes.java#L185),
  I wrote this code before I was working for Red Hat an I am quite happy to 
 license it under Apache or any other license. 
 
 Weld is Apache licensed anyway. I think it's fair to define this approach of 
 creating a type id as not easy.

I would consider it a 'solved problem'. AFAIK the same code should work for any 
CDI impl that needs to generate a deterministic type id.

Stuart


 
 
 Stuart
 
 
 
 
 Does anyone create multiple AnnotatedTypes per class instance? If so, can 
 you please describe:
 
 a) why you need to do this
 b) whether you could reimplement by directly creating beans (given that CDI 
 1.1 allows you to [1])
 c) how much effort it would be to reimplement/how much of your codebase 
 this would affect
 
 Thanks!
 
 Pete
 
 [1]
 
 BeanAttributes ba = beanManager.cerateBeanAttributes(annotatedType);
 InjectionTarget it = beanmanager.createInjectionTarget(annotatedType);
 Bean b = beanManager.createBean(ba, clazz, it);
 
 or
 
 BeanAttributes ba

Re: DS-175 using EJB Transactions for CDI beans in a portable way

2012-07-09 Thread Stuart Douglas 

Just something to be aware of is that invoking this EJB actually does a fair 
bit more than just start a transaction. 

- Available  java:comp and java:module entries may change, as it will be using 
the EjbTransactionHelper JNDI namespace
- This EjbTransactionHelper may have interceptors applied to it by accident 
when using a wildcard mapping in ejb-jar.xml, which could give unexpected 
results
- The EJB will perform exception wrapping, as per the rules in the EJB spec
- Depending on the container this may change the TCCL to the TCCL of the 
deployment with the EJB (AS7 will do this if the EJB is in a different sub 
deployment) 
- The current EJBContext will be changed, so calls to EJBContext will have 
unexpected results
- If no CDI request scope is available one will be created (seems unlikely)

I think that this behaviour has the potential to confuse users.

Stuart

On 10/07/2012, at 4:46 AM, Mark Struberg wrote:

 back to the original problem about how to integrate with container management.
 
 I found a solution which hopefully works for managing CDI beans with EJB CMT 
 - even in a 100% portable way.
 
 Please first take a look what I've done in TransactionHelper. The same could 
 basically be done _inside_ a CmtPersistenceStrategy.
 
 First we create an internal EJB:
 
 
 @Stateless // this is automatically transactional
 
 public class EjbTransactionHelper
 
 public T T invokeTransactional(InvocationContext invocationContext) 
 throws Exception
 {
 return invocationContext.proceed();
 }
 }
 
 
 and then we use this EJB inside the invoke method of the 
 EePersistenceStrategy wrapping the target in a anynomous Callable which just 
 invokes the 'real' target method. 
 
 
 private @Inject EjbTransactionHelper ejbTransaction;
 ...
 public Object execute(InvocationContext invocationContext) throws Exception
 {
 ...
 
 
 and instead of directly invoking invocationContext.proceed() we just use the 
 EJB:
 
 ejbTransaction.invokeTransactional(invocationContext);
 
 Since the EJB will open the transaction for us, we are basically done ...
 
 
 
 Wdyt?
 
 LieGrue,
 strub
 
 
 
 
 
 - Original Message -
 From: Arne Limburg arne.limb...@openknowledge.de
 To: deltaspike-dev@incubator.apache.org 
 deltaspike-dev@incubator.apache.org
 Cc: 
 Sent: Monday, July 9, 2012 8:30 AM
 Subject: AW: AW: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] 
 @Transactional
 
 For api it's fine,
 and then we have two impl modules, JPA and JTA?
 
 Cheers,
 Arne
 
 -Ursprüngliche Nachricht-
 Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] 
 Gesendet: Sonntag, 8. Juli 2012 21:37
 An: deltaspike-dev@incubator.apache.org; Mark Struberg
 Betreff: Re: AW: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] 
 @Transactional
 
 sounds fine
 
 - Romain
 
 
 2012/7/8 Mark Struberg strub...@yahoo.de
 
 maybe we should just rename the jpa module to tx?
 
 There is no single import of any javax.persistence in 
 deltaspike-jpa-api yet.
 
 LieGrue,
 strub
 
 
 
 - Original Message -
 From: Arne Limburg arne.limb...@openknowledge.de
 To: deltaspike-dev@incubator.apache.org 
 deltaspike-dev@incubator.apache.org
 Cc:
 Sent: Sunday, July 8, 2012 8:39 PM
 Subject: AW: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]
 @Transactional
 
 Yes, sounds good.
 The impl of that module could contain the JTA stuff. And the JPA 
 module
 would
 contain the resource local stuff. Everybody that does not need the 
 JTA
 then
 could just use the tx-api and the JPA api and impl.
 
 Cheers,
 Arne
 
 -Ursprüngliche Nachricht-
 Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
 Gesendet: Sonntag, 8. Juli 2012 20:29
 An: deltaspike-dev@incubator.apache.org
 Betreff: Re: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]
 @Transactional
 
 i thought the same, JTA shouldn't depend on JPA. @Transactional 
 should
 be in
 a tx module then JPA could use it.
 
 wdyt?
 
 - Romain
 
 
 2012/7/8 Arne Limburg arne.limb...@openknowledge.de
 
   OK, but I am still not sure where to split it. While 
 implementing  
 this, I got the feeling, that the @Transactional stuff should  
 completely move out of the JPA module. It feeled quite strange 
 that  
 the JTA module depends on the JPA module...
 
   I think, I'll push my stuff right after the 0.3 release and 
 than 
 we  can discuss this at the code-base.
   Maybe I should put all into the JPA module and we split it after  
 
 agreeing to a module structure?
 
   Cheers,
   Arne
 
   -Ursprüngliche Nachricht-
   Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
   Gesendet: Sonntag, 8. Juli 2012 17:48
   An: deltaspike-dev@incubator.apache.org; Mark Struberg
   Betreff: Re: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]  
 @Transactional
 
   +1
 
   - Romain
 
 
   2012/7/8 Mark Struberg strub...@yahoo.de
 
+1 for JTA module.
   
LieGrue,
strub
   
   
   
- Original Message -
 From: Arne Limburg 
 arne.limb...@openknowledge.de

Re: git commit: Removing cache in AnnotationInstanceProvider

2012-05-01 Thread Stuart Douglas 
AFAIK java.lang.reflect.Proxy actually has its own internal cache of proxy 
classes, so removing the cache should not result in the generation of any more 
proxy class objects. 

Also from the WeakHashMap javadoc:


The value objects in a
 * ttWeakHashMap/tt are held by ordinary strong references.  Thus care
 * should be taken to ensure that value objects do not strongly refer to their
 * own keys, either directly or indirectly, since that will prevent the keys
 * from being discarded.


I would be worried that the reference from the annotation would prevent the 
class loader from being cleaned up, thus causing a memory leak.

Stuart
 

On 02/05/2012, at 2:38 PM, Mark Struberg wrote:

 -1
 
 The idea was to use that cache for all instances which don't have any member 
 values to reduce the number of created temporary classes/objects.
 
 
 If we don't do that, we might cause mem leaks over a longer time.
 
 LieGrue,
 strub
 
 
 - Original Message -
 From: lightguar...@apache.org lightguar...@apache.org
 To: deltaspike-comm...@incubator.apache.org
 Cc: 
 Sent: Wednesday, May 2, 2012 5:49 AM
 Subject: git commit: Removing cache in AnnotationInstanceProvider
 
 Updated Branches:
   refs/heads/master c82837e3a - 3a582c96e
 
 
 Removing cache in AnnotationInstanceProvider
 
 
 Project: http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/repo
 Commit: 
 http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/commit/3a582c96
 Tree: 
 http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/tree/3a582c96
 Diff: 
 http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/diff/3a582c96
 
 Branch: refs/heads/master
 Commit: 3a582c96e963939ab7eb566616d9d4a2728896fe
 Parents: c82837e
 Author: Jason Porter lightguar...@apache.org
 Authored: Tue May 1 21:48:43 2012 -0600
 Committer: Jason Porter lightguar...@apache.org
 Committed: Tue May 1 21:48:43 2012 -0600
 
 --
 .../util/metadata/AnnotationInstanceProvider.java  |   58 +--
 .../metadata/AnnotationInstanceProviderTest.java   |   23 +--
 2 files changed, 3 insertions(+), 78 deletions(-)
 --
 
 
 http://git-wip-us.apache.org/repos/asf/incubator-deltaspike/blob/3a582c96/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/util/metadata/AnnotationInstanceProvider.java
 --
 diff --git 
 a/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/util/metadata/AnnotationInstanceProvider.java
  
 b/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/util/metadata/AnnotationInstanceProvider.java
 index 398e429..7f285e6 100644
 --- 
 a/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/util/metadata/AnnotationInstanceProvider.java
 +++ 
 b/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/util/metadata/AnnotationInstanceProvider.java
 @@ -20,8 +20,6 @@
 package org.apache.deltaspike.core.util.metadata;
 
 
 -import org.apache.deltaspike.core.util.ClassUtils;
 -
 import java.io.Serializable;
 import java.lang.annotation.Annotation;
 import java.lang.reflect.InvocationHandler;
 @@ -31,8 +29,6 @@ import java.lang.reflect.Proxy;
 import java.util.Arrays;
 import java.util.Collections;
 import java.util.Map;
 -import java.util.WeakHashMap;
 -import java.util.concurrent.ConcurrentHashMap;
 
 /**
   * pA small helper class to create an Annotation instance of the given 
 annotation class
 @@ -55,11 +51,6 @@ public class AnnotationInstanceProvider implements 
 Annotation, InvocationHandler
  private static final Object[] EMPTY_OBJECT_ARRAY = new Object[0];
  private static final Class[] EMPTY_CLASS_ARRAY = new Class[0];
 
 -// NOTE that this cache needs to be a WeakHashMap in order to prevent a 
 memory leak
 -// (the garbage collector should be able to remove the ClassLoader).
 -private static volatile MapClassLoader, MapString, 
 Annotation annotationCache
 -= new WeakHashMapClassLoader, MapString, Annotation();
 -
  private final Class? extends Annotation annotationClass;
  private final MapString, ? memberValues;
 
 @@ -93,16 +84,7 @@ public class AnnotationInstanceProvider implements 
 Annotation, InvocationHandler
 
  String key = annotationClass.getName() + _ + 
 values.hashCode();
 
 -MapString, Annotation cache = getAnnotationCache();
 -
 -Annotation annotation = cache.get(key);
 -
 -if (annotation == null)
 -{
 -annotation = initAnnotation(key, annotationClass, cache, 
 values);
 -}
 -
 -return (T) annotation;
 +return (T) initAnnotation(key, annotationClass, values);
  }
 
  /**
 @@ -120,47 +102,11 @@ public class AnnotationInstanceProvider implements 
 Annotation, InvocationHandler
 
  private static synchronized T extends Annotation Annotation

Re: [VOTE] Release of Apache DeltaSpike 0.1-incubating

2012-02-07 Thread Stuart Douglas 
+1

Looks good to me. 

Stuart