I am trying to run the cdi tck:
It seems this test is to verify whether both web modules receive the
initilization event of ApplicationScoped. The confusing bit is that the
test directly verfies whether both events are received without trying to
send request to activate the web modules. I think the test assume web
modules are active and did not consider the fact of that some application
server starts the modules in a lazy mode.
The CDI spec says:
The application scope is active:
• during the service() method of any servlet in the web application, during
method of any servlet filter and when the container calls any
HttpSessionListener, AsyncListener or ServletRequestListener
According to cdi spec 6.7.3:
An event with qualifier @Initialized(ApplicationScoped.class) is fired when
context is initialized and an event with qualifier
@Destroyed(ApplicationScoped.class) is fired
when the application is destroyed. The event payload is:
• the ServletContext if the application is a web application deployed to a
Servlet container, or
• any java.lang.Object for other types of application.
The spec did not say whether the event should be recieved. In my
environment, if the web module url is hit, the obeserved event will be
I think we have implemented this correctly as I can confirm the application
scope is active when a request is sent and the event of
@Initialized(ApplicationScoped.class) is received as well but the test
assumes the web module is active automatically without even needing to send
the first request.
Can someone shed some lights on this? What is the test trying to do? I am
suggesting the test should be updated to send the first request first
before checking the size of the obsevers.
I did not directly send to cdi tck as I would like to get some input from
weld dev list first.
In the past, I talked to Jozef/Martin regarding whether Weld 2.2.x runs
against CDI 1.1 cts or CDI 1.2 cts. If I can remember correctly, I was told
Weld 2.2.x runs against CDI 1.2 cts only.
Can someone confirm whether you expect Weld 2.2.x passes CDI 1.1 cts as
well or you have stopped maintaining CDI 1.1 cts and only runs against CDI
We found the same test does different things between CDI 1.1 cts and CDI
I have a few questions on interceptors:
1. CDI Interceptors on cdi beans
Will the interceptors share the same creational context as the bean it is
associated with? Will Weld managed the cdi interceptors as well as the
@Interceptors don't work on other cdi beans except ejb and managed beans,
2. Interceptors on ejb beans or managed beans
I think the integrator needs to create these @Interceptors and cdi
interceptors. Will these interceptors use the non-contextual creational
context (scope @Dependent) or use the ejb or managed bean's creational
Will Weld destroy the interceptors when the associated beans are destroyed
or the integrator need to destroy them? This logic applicable to both cdi
interceptors and @Interceptors style interceptors, right?
3. Interceptors on JavaEE components
I think this interceptors are created by Weld when the JavaEE component
classes are created, right? By the way, how can the container make sure to
destroy the interceptors?
I am trying to run cdi cts and failed on the following test:
The test is to test the following produer:
@Produces @WebServiceRef private static MyClass wsRef;
On further investigation,it seems like Weld has a special call that it
makes when a producer field is static but also annotated with a JavaEE
resource. Eventually that calls to JaxwsInjectionServices, a weld SPI that
we don't implement and falls back to just getting the value of the static
field, which may not be set.
We followed the Weld integration guide which said that we can handle JavaEE
resource injection either by implementing the SPI InjectionServices where
we can hook every injection call and to additional injection ourselves, or
by implementing EjbInjectionServices, JaxwsInjectionServices,
JpaInjectionServices and ResourceInjectionServices, all of which return a
factory which produces the instance that weld will then inject.
We implemented the former because it lets us just call our injectionengine,
but Weld doesn't seem to use this SPI at all when handling static producer
fields. Can someone confirm or give me some pointers how to fix this
We use weld in our commercial product and therefore need to know the ECCN for it.
The ECCN is an international Export control and compliance number that is necessary for EVERY Export. Most of the european countries specify their goods according to the european commerce control list (EG dual-use list : http://ec.europa.eu/trade/index_en.htm).
So for export of a commercial Software using weld ( or any other open source or OEM Software), we need to document the libs, on one side to comply with license obligations and on the other side the ECCNs for Export restrictions. Please note, as the US regulations also care about re-export of US items ( any stuff that contains US Content above a certain Limit), we need to specify both; the EU-ECCN and the US-ECCN and hopefully the US license exception that applies (e.g. TSU for open source).
So please specify the ECCN for weld or answer the following questions:
- Country of origin ( where is weld Software mainly developed)
- is there US Content in there? ( e.g. other open source libs)
- Is the SW designed or modified to use cryptography performing any cryptographic function other than authentication or digital signature? (y/n)
-- key length symetric
-- Bit length asymmetric
Thanks and kind regards
Mit freundlichen Grüßen / Kind Regards / Com os melhores cumprimentos!
Coriant R&D GmbH
SW OSS&Transnet TNTC DE
Tel: +49 89 5402 15138
[cid:image004.png@01D08645.87B02DC0]Think before you print
registered under / registriert unter: HRB 202750 | WEEE-Reg.-No. DE 77603797
Local Court of Munich / Amtsgericht München
Registered Office: Munich (Germany) / Sitz: München
Managing Directors / Geschäftsführer: Peter Streit, Mike MacKinnon
VAT ID / USt-IdNr.: DE288084869
I am trying to run cdi 1.2 tck:
I got this following failure:
java.lang.IllegalStateException: Singleton not set for STATIC_INSTANCE =>
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
From the stack trace, two strange things are happening:
1) the TCK code is calling into org.jboss.weld.Container which is an
internal Weld class which should not be visible to application so the
application should not need to load them
2) the TCK code is calling Container.instance() with no arguments, which
should not be called. We always use Container.instance(contextId), in
accordance with Weld doc A.3.2.4. Singleton SPI (this should be used in
Can someone help to explain why the tck test was done this way? Is it
Thank you Jozef or your reply. have brought this discussion in the cdi dev
as I think the spec is contradicting itself. Anyway, this question is
related to one tck test
This tck is to test a scenario where no classes in the web-inf\classes but
one beans.xml. In this beans.xml, an invalid class was specified in the
alternative list. The test is expecting a deployment. In my interpretation,
I won't create any archive for it as there is no classes. What is the value
to create one with beans.xml but nothing else (by the way, no other
accessible bean archives either). What is the value of this test? I think
the test should be modified to include a class. Thoughts?
On Mon, May 4, 2015 at 7:30 AM, Jozef Hartinger <jharting(a)redhat.com> wrote:
> Hi Emily,
> jar1 and jar2 would be bean archives on their own. If such archive
> declares beans.xml then that one is used. Otherwise, the bean archive may
> be implicit (no beans.xml but bean-defining annotation). Either way, no
> other beans.xml file is used instead for that particular jar.
> On 04/30/2015 11:34 PM, Emily Jiang wrote:
> Thanks Jozef! I figured out why I did not get an error:
> my war:
> web-inf\beans.xml (containing invalid class as alternatives)
> [no web-inf\classes]
> In either jar1.jar or jar2.jar, there is no beans.xml and no
> bean-defining annotations. Do you think the jar1.jar and jar2.jar should
> use the beans.xml in the web-inf? If yes, what if there is beans.xml
> packaged in either jar1.jar or jar2.jar? I cannot find any clear
> instruction on this scenario.
> On Thu, Apr 30, 2015 at 6:24 AM, Jozef Hartinger <jharting(a)redhat.com>
>> Hi Emily,
>> Weld performs all these validations.
>> On 04/29/2015 11:52 PM, Emily Jiang wrote:
>> CDI1.2 spec section 8.2.2 says:
>> In the beans.xml
>> Each child <class> element must specify the name of a decorator bean
>> class. If there is no class with the specified name, or if the class with
>> the specified name is not a decorator bean class, the container
>> automatically detects the problem and treats it as a deployment problem.
>> If the same class is listed twice under the <decorators> element, the
>> container automatically detects the problem and treats it as a deployment
>> Will Weld do the validation or Weld expects the integrator to do the
>> I am confused about what validations are done by the spec reference
>> implemenatation (RI) or RI consumer.
>> Emily Jiang
>> weld-dev mailing firstname.lastname@example.org://lists.jboss.org/mailman/listinfo/weld-dev
> Emily Jiang