AW: Interceptors not being called in JUnit-aware CDI environment
Hey Romain, that was the missing piece of the puzzle and lets me step down in embarrassment for such an idiotic mistake. I've had the assumtion that for a maven surefire test, the beans.xml provided in src/main/resources/META-INF which IS obviously used, is enough, but after you pointed this out, I simply added another one under src/test/resources/META-INF and voilá, getBeans() returns a Bean that I can retrieve an instance from, that indeed will make interceptors work. Thank you very much for your help, Heiko -Ursprüngliche Nachricht- Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] Gesendet: Freitag, 7. Februar 2014 08:55 An: dev@deltaspike.apache.org Betreff: Re: Interceptors not being called in JUnit-aware CDI environment = == ATTENTION! This message contains suspicious URL(s) possibly redirecting to malicious content. Our security gateways target known problem URLs like freeweb or URL Shorteners that are being abused by spammers. Some examples would be groups.google.com or tinyurl.com. Please check the sender and hyperlinks in the e-mail accurately before clicking on a link. If this email seems obviously bad to you please delete it. More information is available on our website Information Security @ Daimler: http://intra.corpintra.net/intra- is-e/spam = == ACHTUNG! Diese E-Mail enthält verdächtige URLs welche möglicherweise auf schädlichen Inhalt verweisen. Die Security Gateways prüfen auf bekannte Problem-URLs wie zum Beispiel URL-Abkürzungen, die bevorzugt von Spammern mißbraucht werden (tinyurl.com, groups.google.com, ...). Bitte prüfen Sie den Absender und die URLs in dieser E-Mail gewissenhaft bevor sie die verknüpften Inhalte aufrufen. Bitte löschen Sie diese E-Mail, wenn Sie der Meinung sind, daß sich der Verdacht bestätigt. Weitere Informationen zu unerwünschter E-Mail / SPAM finden Sie auf den Seiten der Informationssicherheit bei Daimler unter: http://intra.corpintra.net/intra-is- d/spam = == is you test class scanned by cdi? I mean did you provide a META- INF/beans.xml for tests? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-07 it-media.k...@daimler.com: Hello Romain, thank you for your fast response. Yes I want to intercept the test itself. I've checked into various ways on how to actually create a bean, however nothing worked out. You mention to call beanManager.getXXX() but for my point that is not enough information. I tried to retrieve the beans of the test class via beanManager.getBeans() but regardless of what I try as annotation literals there (non, Any, etc.) nothing works, the list is always empty. What method exactly did you have in mind here? Thanks, Heiko -Ursprüngliche Nachricht- Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] Gesendet: Freitag, 7. Februar 2014 08:26 An: dev@deltaspike.apache.org Betreff: Re: Interceptors not being called in JUnit-aware CDI environment = == ATTENTION! This message contains suspicious URL(s) possibly redirecting to malicious content. Our security gateways target known problem URLs like freeweb or URL Shorteners that are being abused by spammers. Some examples would be groups.google.com or tinyurl.com. Please check the sender and hyperlinks in the e-mail accurately before clicking on a link. If this email seems obviously bad to you please delete it. More information is available on our website Information Security @ Daimler: http://intra.corpintra.net/intra- is-e/spam = == ACHTUNG! Diese E-Mail enthält verdächtige URLs welche möglicherweise auf schädlichen Inhalt verweisen. Die Security Gateways prüfen auf bekannte Problem-URLs wie zum Beispiel URL-Abkürzungen, die bevorzugt von Spammern mißbraucht werden (tinyurl.com, groups.google.com, ...). Bitte prüfen Sie den Absender und die URLs in dieser E-Mail gewissenhaft bevor sie die verknüpften Inhalte aufrufen. Bitte löschen Sie diese E-Mail, wenn Sie der Meinung sind, daß sich der Verdacht bestätigt. Weitere Informationen zu unerwünschter E-Mail / SPAM finden Sie auf den Seiten der Informationssicherheit bei Daimler unter: http://intra.corpintra.net/intra-is- d/spam = == HI You want to intercept the test? so it means the runner needs to invoke business methods of the test class which is not the case by default (ie result shouldn't be built from a newInstance() but from a beanManager.getXXX()). Romain
[jira] [Commented] (DELTASPIKE-518) DS Data should support Wrapped JPA APIs
[ https://issues.apache.org/jira/browse/DELTASPIKE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894286#comment-13894286 ] Thomas Hug commented on DELTASPIKE-518: --- Looks good. I'd prefer an Arquillian test though so we can also get rid of the OpenJPA test dependency. DS Data should support Wrapped JPA APIs --- Key: DELTASPIKE-518 URL: https://issues.apache.org/jira/browse/DELTASPIKE-518 Project: DeltaSpike Issue Type: Bug Components: Data-Module Affects Versions: 0.5 Reporter: Jean-Louis MONTEIRO Assignee: Romain Manni-Bucau Fix For: 0.6 Attachments: DELTASPIKE-518.patch In containers like TomEE, you usually don't get the provider implementation directly but a wrapper instead. Currently, DS data fails saying it does not know the provider. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [jira] [Commented] (DELTASPIKE-518) DS Data should support Wrapped JPA APIs
Thanks Thomas. Will you do that yourself, or do you want me to do the arquillian test and submit a new patch? JLouis 2014-02-07 Thomas Hug (JIRA) j...@apache.org: [ https://issues.apache.org/jira/browse/DELTASPIKE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894286#comment-13894286] Thomas Hug commented on DELTASPIKE-518: --- Looks good. I'd prefer an Arquillian test though so we can also get rid of the OpenJPA test dependency. DS Data should support Wrapped JPA APIs --- Key: DELTASPIKE-518 URL: https://issues.apache.org/jira/browse/DELTASPIKE-518 Project: DeltaSpike Issue Type: Bug Components: Data-Module Affects Versions: 0.5 Reporter: Jean-Louis MONTEIRO Assignee: Romain Manni-Bucau Fix For: 0.6 Attachments: DELTASPIKE-518.patch In containers like TomEE, you usually don't get the provider implementation directly but a wrapper instead. Currently, DS data fails saying it does not know the provider. -- This message was sent by Atlassian JIRA (v6.1.5#6160) -- Jean-Louis
Re: [DISCUSS] DeltaSpike Launch Module
Agree, it sounds good but I'd rather focus on (finnally!) shipping DS-1.0 for now. I'll give it a tough test drive in the next weeks to see what we miss before the milestone. John, you could probably do a draft on github? LieGrue, stru On Friday, 7 February 2014, 6:15, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi I see the use case but deltaspike needs so much work on existing code (jsf, security, transactional, data for the one I see) that I think we shouldnt add new things while we dont propose something working fine out of the box. Wdyt? Le 7 févr. 2014 02:31, John D. Ament john.d.am...@gmail.com a écrit : Hi all I've been working a bit on a POC. The idea is to run a light weight Java SE application that does some basic bootstrapping and container services. The SE app would be configured with a basic socket listener using Netty and delegate requests to a REST provider. The idea behind it is that CDI forms the low level core of the container, where a developer can deploy services they build on their own. The application is meant to be an API type server (deploy REST APIs) that runs using Netty, starts up a CDI container using DeltaSpike Container Control API. The launch module would handle the basic bootstrap of the rest provider, instantiating the CDI container using ContainerControl, and handle the necessary bootstrap for lookup up resources and registering with the provider. This type of module would compete with Spring Boot. Currently what I have leverages Weld 2.1.1 and RestEasy. The equivalent should work for CXF. There's no hard dependency on Weld. I was thinking the module structure would include an api, spi, impl-resteasy and impl-cxf. Some things I'd like to add: - Automatic bootstrap of JPA (via JPA module) - Transaction intercepting (probably need to pull in the Geronimo lib) - Probably also register some providers automatically as well. Let me know your thoughts. John
Re: [jira] [Commented] (DELTASPIKE-518) DS Data should support Wrapped JPA APIs
If it can wait 'til the weekend I can pick it up :-) On Fri, Feb 7, 2014 at 9:21 AM, Jean-Louis MONTEIRO jeano...@gmail.comwrote: Thanks Thomas. Will you do that yourself, or do you want me to do the arquillian test and submit a new patch? JLouis 2014-02-07 Thomas Hug (JIRA) j...@apache.org: [ https://issues.apache.org/jira/browse/DELTASPIKE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894286#comment-13894286 ] Thomas Hug commented on DELTASPIKE-518: --- Looks good. I'd prefer an Arquillian test though so we can also get rid of the OpenJPA test dependency. DS Data should support Wrapped JPA APIs --- Key: DELTASPIKE-518 URL: https://issues.apache.org/jira/browse/DELTASPIKE-518 Project: DeltaSpike Issue Type: Bug Components: Data-Module Affects Versions: 0.5 Reporter: Jean-Louis MONTEIRO Assignee: Romain Manni-Bucau Fix For: 0.6 Attachments: DELTASPIKE-518.patch In containers like TomEE, you usually don't get the provider implementation directly but a wrapper instead. Currently, DS data fails saying it does not know the provider. -- This message was sent by Atlassian JIRA (v6.1.5#6160) -- Jean-Louis
Re: [DISCUSS] DeltaSpike Launch Module
+1 The core is very stable. Users are afraid by 0.5 or 0.6 in terms of quality. From my experience with DS, core module at least is very stable. JSF and Data work fine as well. Currently, we don't have a 1.0 mainly because some other modules are not totally merged nor stable maybe, right? Jean-Louis 2014-02-07 Mark Struberg strub...@yahoo.de: Agree, it sounds good but I'd rather focus on (finnally!) shipping DS-1.0 for now. I'll give it a tough test drive in the next weeks to see what we miss before the milestone. John, you could probably do a draft on github? LieGrue, stru On Friday, 7 February 2014, 6:15, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi I see the use case but deltaspike needs so much work on existing code (jsf, security, transactional, data for the one I see) that I think we shouldnt add new things while we dont propose something working fine out of the box. Wdyt? Le 7 févr. 2014 02:31, John D. Ament john.d.am...@gmail.com a écrit : Hi all I've been working a bit on a POC. The idea is to run a light weight Java SE application that does some basic bootstrapping and container services. The SE app would be configured with a basic socket listener using Netty and delegate requests to a REST provider. The idea behind it is that CDI forms the low level core of the container, where a developer can deploy services they build on their own. The application is meant to be an API type server (deploy REST APIs) that runs using Netty, starts up a CDI container using DeltaSpike Container Control API. The launch module would handle the basic bootstrap of the rest provider, instantiating the CDI container using ContainerControl, and handle the necessary bootstrap for lookup up resources and registering with the provider. This type of module would compete with Spring Boot. Currently what I have leverages Weld 2.1.1 and RestEasy. The equivalent should work for CXF. There's no hard dependency on Weld. I was thinking the module structure would include an api, spi, impl-resteasy and impl-cxf. Some things I'd like to add: - Automatic bootstrap of JPA (via JPA module) - Transaction intercepting (probably need to pull in the Geronimo lib) - Probably also register some providers automatically as well. Let me know your thoughts. John -- Jean-Louis
AW: AW: Interceptors not being called in JUnit-aware CDI environment
Hello Mark,
thank you for your input. Your idea would have been much easier than what I did
:-)
When you write a Junit Runner, you have the ability to control the test class
creation by overwriting createTest() and returning your instance. By default
this is simply the newInstance() call for the constructor with no arguments of
the test class. The following code will therefore not only provide injection
but even create a fully creational contexted bean that even will trigger
interceptors. I've made sure though, that after calling all
'AfterClass'-Annotations, the creational context is released too, so the bean
does not stick around.
I do not really have a clue though how this could be done with TestNg.
I might miss out some clearContexts() here. I thought about cleaning the
contexts before a new test-method is run, however I loose all beans discovered
and created while the container booted, and that lead to failing tests. I need
the container being created BEFORE createTest() is called to be able to do the
bean creation. I have to dive into this more deeply. Another Idea would be to
simply boot the container again before each method and shut it down afterwards,
though this will slow down tests.
public class TestRunner extends BlockJUnit4ClassRunner
{
private Class? clazz;
private CreationalContext? creationalContext;
public TestRunner(final Class? clazz) throws InitializationError
{
super(clazz);
this.clazz = clazz;
cdiContainer = CdiContainerLoader.getCdiContainer();
cdiContainer.boot();
cdiContainer.getContextControl().startContexts();
}
@Override
protected Object createTest()
throws Exception
{
return createTest(clazz);
}
@SuppressWarnings(unchecked)
private T T createTest(final ClassT testClass) throws Exception
{
final BeanManager beanManager = cdiContainer.getBeanManager();
final SetBean? beans = beanManager.getBeans(testClass);
assert !beans.isEmpty();
final Bean? bean = beans.iterator().next();
creationalContext = beanManager.createCreationalContext(bean);
final T result = (T) beanManager.getReference(bean, testClass,
creationalContext);
return result;
}
@Override
protected Statement withAfterClasses(final Statement statement)
{
final Statement defaultStatement = super.withAfterClasses(statement);
return new Statement()
{
@Override
public void evaluate()
throws Throwable
{
try
{
defaultStatement.evaluate();
}
finally
{
creationalContext.release();
}
}
};
}
Regards,
Heiko
-Ursprüngliche Nachricht-
Von: Mark Struberg [mailto:strub...@yahoo.de]
Gesendet: Freitag, 7. Februar 2014 09:29
An: dev@deltaspike.apache.org
Betreff: Re: AW: Interceptors not being called in JUnit-aware CDI environment
=
==
ATTENTION! This message contains suspicious URL(s) possibly redirecting to
malicious content. Our security gateways target known problem URLs like
freeweb or URL Shorteners that are being abused by spammers. Some
examples would be groups.google.com or tinyurl.com. Please check the sender
and hyperlinks in the e-mail accurately before clicking on a link. If this
email
seems obviously bad to you please delete it. More information is available on
our website Information Security @ Daimler: http://intra.corpintra.net/intra-
is-e/spam
=
==
ACHTUNG! Diese E-Mail enthält verdächtige URLs welche möglicherweise auf
schädlichen Inhalt verweisen. Die Security Gateways prüfen auf bekannte
Problem-URLs wie zum Beispiel URL-Abkürzungen, die bevorzugt von
Spammern mißbraucht werden (tinyurl.com, groups.google.com, ...). Bitte
prüfen Sie den Absender und die URLs in dieser E-Mail gewissenhaft bevor sie
die verknüpften Inhalte aufrufen. Bitte löschen Sie diese E-Mail, wenn Sie der
Meinung sind, daß sich der Verdacht bestätigt. Weitere Informationen zu
unerwünschter E-Mail / SPAM finden Sie auf den Seiten der
Informationssicherheit bei Daimler unter: http://intra.corpintra.net/intra-is-
d/spam
=
==
Hi Heiko!
Afaik all unit runners (junit, testng) do create and manage the test class
instances themselfs. We only do injection into those existing instances. With
other words: we just fill the injection points. Whenever I need to have an
intercepted method, I create a public static inner class in my test. E.g.
when I
need a @Transactional DbHelper with a cleanup() method which should run in
an own transaction.
private @Inject DbHelper dbHelper;
pubic
Re: AW: Interceptors not being called in JUnit-aware CDI environment
Side note: you can also use a JUnit @Rule ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-07 Gerhard Petracek gerhard.petra...@gmail.com:
hi heiko,
you can use CdiTestRunner + configure true for:
deltaspike.testcontrol.use_test_class_as_cdi_bean
regards,
gerhard
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2014-02-07 it-media.k...@daimler.com:
Hello Mark,
thank you for your input. Your idea would have been much easier than what
I did :-)
When you write a Junit Runner, you have the ability to control the test
class creation by overwriting createTest() and returning your instance. By
default this is simply the newInstance() call for the constructor with no
arguments of the test class. The following code will therefore not only
provide injection but even create a fully creational contexted bean that
even will trigger interceptors. I've made sure though, that after calling
all 'AfterClass'-Annotations, the creational context is released too, so
the bean does not stick around.
I do not really have a clue though how this could be done with TestNg.
I might miss out some clearContexts() here. I thought about cleaning the
contexts before a new test-method is run, however I loose all beans
discovered and created while the container booted, and that lead to failing
tests. I need the container being created BEFORE createTest() is called to
be able to do the bean creation. I have to dive into this more deeply.
Another Idea would be to simply boot the container again before each method
and shut it down afterwards, though this will slow down tests.
public class TestRunner extends BlockJUnit4ClassRunner
{
private Class? clazz;
private CreationalContext? creationalContext;
public TestRunner(final Class? clazz) throws InitializationError
{
super(clazz);
this.clazz = clazz;
cdiContainer = CdiContainerLoader.getCdiContainer();
cdiContainer.boot();
cdiContainer.getContextControl().startContexts();
}
@Override
protected Object createTest()
throws Exception
{
return createTest(clazz);
}
@SuppressWarnings(unchecked)
private T T createTest(final ClassT testClass) throws Exception
{
final BeanManager beanManager = cdiContainer.getBeanManager();
final SetBean? beans = beanManager.getBeans(testClass);
assert !beans.isEmpty();
final Bean? bean = beans.iterator().next();
creationalContext = beanManager.createCreationalContext(bean);
final T result = (T) beanManager.getReference(bean, testClass,
creationalContext);
return result;
}
@Override
protected Statement withAfterClasses(final Statement statement)
{
final Statement defaultStatement =
super.withAfterClasses(statement);
return new Statement()
{
@Override
public void evaluate()
throws Throwable
{
try
{
defaultStatement.evaluate();
}
finally
{
creationalContext.release();
}
}
};
}
Regards,
Heiko
-Ursprüngliche Nachricht-
Von: Mark Struberg [mailto:strub...@yahoo.de]
Gesendet: Freitag, 7. Februar 2014 09:29
An: dev@deltaspike.apache.org
Betreff: Re: AW: Interceptors not being called in JUnit-aware CDI
environment
=
==
ATTENTION! This message contains suspicious URL(s) possibly redirecting
to
malicious content. Our security gateways target known problem URLs like
freeweb or URL Shorteners that are being abused by spammers. Some
examples would be groups.google.com or tinyurl.com. Please check the
sender
and hyperlinks in the e-mail accurately before clicking on a link. If
this email
seems obviously bad to you please delete it. More information is
available on
our website Information Security @ Daimler:
http://intra.corpintra.net/intra-
is-e/spam
=
==
ACHTUNG! Diese E-Mail enthält verdächtige URLs welche möglicherweise auf
schädlichen Inhalt verweisen. Die Security Gateways prüfen auf bekannte
Problem-URLs wie zum Beispiel URL-Abkürzungen, die bevorzugt von
Spammern mißbraucht werden (tinyurl.com, groups.google.com, ...). Bitte
prüfen Sie den Absender und die URLs in dieser E-Mail gewissenhaft bevor
sie
die verknüpften Inhalte aufrufen. Bitte löschen Sie diese E-Mail, wenn
Sie der
Meinung sind, daß sich der Verdacht bestätigt. Weitere
[jira] [Updated] (DELTASPIKE-480) view-config validation
[ https://issues.apache.org/jira/browse/DELTASPIKE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-480: Attachment: (was: DELTASPIKE-480.patch) view-config validation -- Key: DELTASPIKE-480 URL: https://issues.apache.org/jira/browse/DELTASPIKE-480 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.5 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.6 Attachments: DELTASPIKE-480.patch view-configs should get validated (if there are the corresponding files and folders) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (DELTASPIKE-480) view-config validation
[ https://issues.apache.org/jira/browse/DELTASPIKE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-480: Attachment: DELTASPIKE-480.patch view-config validation -- Key: DELTASPIKE-480 URL: https://issues.apache.org/jira/browse/DELTASPIKE-480 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.5 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.6 Attachments: DELTASPIKE-480.patch view-configs should get validated (if there are the corresponding files and folders) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (DELTASPIKE-519) ClassLoader leak in ClassDeactivationUtils
Moritz Bechler created DELTASPIKE-519:
-
Summary: ClassLoader leak in ClassDeactivationUtils
Key: DELTASPIKE-519
URL: https://issues.apache.org/jira/browse/DELTASPIKE-519
Project: DeltaSpike
Issue Type: Bug
Components: Core
Affects Versions: 0.5
Reporter: Moritz Bechler
Priority: Critical
ClassDeactivationUtils statically holds two maps (classDeactivatorMap,
activationStatusCache) one having a classloader as key and the other a class.
These entries are never removed resulting in leaks of the TCCL or the
classloaders of Deactivatable classes if they do not equal the classloader
loading deltaspike.
Suggested fix:
{code}
/**
* This Map holds the ClassLoader as first level to make it possible to
have different configurations per
* WebApplication in an EAR or other Multi-ClassLoader scenario.
*
* The Map then contains a List of {@link ClassDeactivator}s in order of
their configured ordinal.
*/
private static MapClassLoader, ListClassDeactivator classDeactivatorMap
= Collections.synchronizedMap(new WeakHashMapClassLoader,
ListClassDeactivator());
/**
* Cache for the result. It won't contain many classes but it might be
accessed frequently.
* Valid entries are only true or false. If an entry isn't available or
null, it gets calculated.
*/
private static MapClass? extends Deactivatable, Boolean
activationStatusCache
= Collections.synchronizedMap(new WeakHashMapClass? extends
Deactivatable, Boolean());
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-519) ClassLoader leak in ClassDeactivationUtils
[
https://issues.apache.org/jira/browse/DELTASPIKE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894475#comment-13894475
]
Romain Manni-Bucau commented on DELTASPIKE-519:
---
I think we have it for BeanManagerProvider too. We spoke about having a map
store in the classloader (using Unsafe), it could do the trick and would avoid
the need to track classloaders
ClassLoader leak in ClassDeactivationUtils
--
Key: DELTASPIKE-519
URL: https://issues.apache.org/jira/browse/DELTASPIKE-519
Project: DeltaSpike
Issue Type: Bug
Components: Core
Affects Versions: 0.5
Reporter: Moritz Bechler
Priority: Critical
ClassDeactivationUtils statically holds two maps (classDeactivatorMap,
activationStatusCache) one having a classloader as key and the other a class.
These entries are never removed resulting in leaks of the TCCL or the
classloaders of Deactivatable classes if they do not equal the classloader
loading deltaspike.
Suggested fix:
{code}
/**
* This Map holds the ClassLoader as first level to make it possible to
have different configurations per
* WebApplication in an EAR or other Multi-ClassLoader scenario.
*
* The Map then contains a List of {@link ClassDeactivator}s in order of
their configured ordinal.
*/
private static MapClassLoader, ListClassDeactivator
classDeactivatorMap
= Collections.synchronizedMap(new WeakHashMapClassLoader,
ListClassDeactivator());
/**
* Cache for the result. It won't contain many classes but it might be
accessed frequently.
* Valid entries are only true or false. If an entry isn't available or
null, it gets calculated.
*/
private static MapClass? extends Deactivatable, Boolean
activationStatusCache
= Collections.synchronizedMap(new WeakHashMapClass? extends
Deactivatable, Boolean());
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (DELTASPIKE-517) improved weld-support
[ https://issues.apache.org/jira/browse/DELTASPIKE-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-517. - Resolution: Fixed improved weld-support - Key: DELTASPIKE-517 URL: https://issues.apache.org/jira/browse/DELTASPIKE-517 Project: DeltaSpike Issue Type: Improvement Components: JPA-Module, Security-Module Affects Versions: 0.5 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.6 Attachments: DELTASPIKE-517.patch with some versions of weld (e.g. 1.1.16) InvocationContext#getTarget returns the subclass-proxy. due to the proxy-class, we can't extract the correct annotations. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-519) ClassLoader leak in ClassDeactivationUtils
[
https://issues.apache.org/jira/browse/DELTASPIKE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894508#comment-13894508
]
Romain Manni-Bucau commented on DELTASPIKE-519:
---
excepted startup loader and runtime/shutdown loader can be different
ClassLoader leak in ClassDeactivationUtils
--
Key: DELTASPIKE-519
URL: https://issues.apache.org/jira/browse/DELTASPIKE-519
Project: DeltaSpike
Issue Type: Bug
Components: Core
Affects Versions: 0.5
Reporter: Moritz Bechler
Priority: Critical
ClassDeactivationUtils statically holds two maps (classDeactivatorMap,
activationStatusCache) one having a classloader as key and the other a class.
These entries are never removed resulting in leaks of the TCCL or the
classloaders of Deactivatable classes if they do not equal the classloader
loading deltaspike.
Suggested fix:
{code}
/**
* This Map holds the ClassLoader as first level to make it possible to
have different configurations per
* WebApplication in an EAR or other Multi-ClassLoader scenario.
*
* The Map then contains a List of {@link ClassDeactivator}s in order of
their configured ordinal.
*/
private static MapClassLoader, ListClassDeactivator
classDeactivatorMap
= Collections.synchronizedMap(new WeakHashMapClassLoader,
ListClassDeactivator());
/**
* Cache for the result. It won't contain many classes but it might be
accessed frequently.
* Valid entries are only true or false. If an entry isn't available or
null, it gets calculated.
*/
private static MapClass? extends Deactivatable, Boolean
activationStatusCache
= Collections.synchronizedMap(new WeakHashMapClass? extends
Deactivatable, Boolean());
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
Re: Optimizing the integration tests
Hey Ron, thanks for sharing these details. I created a separate arquillian.xml file for AS7 and JBoss. https://github.com/apache/deltaspike/commit/ce875fde3fe5421c6d12bd43019fedaee8af5923 I guess this setup should work fine now. Christian 2014-02-04 10:18 GMT+01:00 Ron Smeral rsme...@redhat.com: Christian, I just found out, that adding protocol type=Servlet 3.0 / to the container element in arquillian.xml only configures (does not select) an already selected protocol. If no protocol is selected using defaultProtocol, then the container's default is used. And the default for AS7 is, sadly, jmx-as7, which is intended for internal testing of the container and makes tests unstable. What could be done, is to create arquillian-owb.xml in test-utils, and add arquillian.xmlarquillian-owb.xml/arquillian.xml to the systemProperties in OWB profile. Or the other way around for JBoss. Ron On 3.2.2014 17:23, Christian Kaltepoth wrote: @Ron I just tried that. The result is this: java.lang.IllegalArgumentException: No org.jboss.arquillian.container.spi.client.protocol.metadata.HTTPContext found in org.jboss.arquillian.container.spi.client.protocol. metadata.ProtocolMetaData. Servlet protocol can not be used at org.jboss.arquillian.protocol.servlet.BaseServletProtocol.getExecutor( BaseServletProtocol.java:64) at org.jboss.arquillian.protocol.servlet.BaseServletProtocol.getExecutor( BaseServletProtocol.java:35) at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter. getContainerMethodExecutor(RemoteTestExecuter.java:136) at org.jboss.arquillian.container.test.impl.execution. RemoteTestExecuter.execute(RemoteTestExecuter.java:119) What if we just add *protocol type=Servlet 3.0 /* to all the AS7 and Wildfly profiles? Wouldn't this fix all our problems? Christian 2014-02-03 Ron Smeral rsme...@redhat.com: Hi Christian, the reason for this could be, that in parent/code/pom.xml, the 'org.jboss.arquillian.protocol:arquillian-protocol-servlet' dependency is not declared for any non-JBoss profile (OWB, tomee, glassfish, ..). Could you try it with the dependency declared? Ron On 3.2.2014 10:51, Christian Kaltepoth wrote: @gerhard: I was getting this when running the build: Caused by: java.lang.IllegalStateException: Defined default protocol Servlet 3.0 can not be found on classpath at org.jboss.arquillian.container.test.impl.client.protocol. ProtocolRegistryCreator.createRegistry(ProtocolRegistryCreator.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.arquillian.core.impl.ObserverImpl.invoke( ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers( EventContextImpl.java:99) The weird thing is that Maven simply doesn't run the tests in this case which leads to a successful build. Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 Full log of running mvn clean -POWB -Dowb.version=1.1.8 on core-impl with the default protocol entry: http://pastebin.com/raw.php?i=1hk9nxmZ Christian 2014-02-02 Gerhard Petracek gerhard.petra...@gmail.com: @christian: locally i've tested the owb-, weld- and some build-managed-profiles with the defaultProtocol you removed and everything is working on my machine. - please provide further details. regards, gerhard 2014-02-01 Christian Kaltepoth christ...@kaltepoth.de: @Ron @Jason The defaultProtocol was only used in a single arquillian.xml file of the 8 different ones we had before. I had to remove it because the plain Weld + OWB integration tests started to fail with it (at least for me) for some reason. Christian 2014-01-31 Jason Porter lightguard...@gmail.com: The JMX protocol for Wildfly / AS is horrible and for any sort of application or framework the servlet adaptor should be used. Yes, it's a little slower, but it will give you the full environment you're used to using when you develop. On Fri, Jan 31, 2014 at 1:59 PM, Ron Smeral rsme...@redhat.com wrote: Hi Christian, I see you recently removed defaultProtocol from arquillian.xml. Is there any reason not to have it there? The now default JMX protocol seems to be causing test stability issues, I can't succesfully run for example the Data module tests. I'm not sure why this happens. Have you maybe encountered this too? Also, just FYI, we now have a job 'DeltaSpike-wildfly-daily' at hudson.jboss.org which tests the wildfly-build-managed profile. It will be sending mails to commits@deltaspike. Ron On 25.1.2014 08:36, Christian Kaltepoth wrote:
