Maintenance release
by Gavin King
Folks, I want to start work on the first CDI maintenance release, and
push it out fairly quickly. We've already discussed a couple of things
that we wanted in CDI 1.0, but had to delay to the maintenance
release:
* Bean declaration at constructor level
* Abstract producer methods
* Injection into static members
I want to discuss these things in separate threads.
I also have a list of enhancements to the portable extension SPI,
which was the least-mature part of the spec, and I would like to
discuss with you guys whether some of those enhancements could/should
be rolled into the maintenance release.
For now, I just want to update the spec with a list of clarifications
that have cropped up. Please read over these items and speak up if you
have an opinion on any of them!
++ Methods of abstract decorators
The CDI 1.0 spec does not define what happens with abstract methods of
an abstract decorator class. This was an oversight. We should probably
say:
* If a decorator class declares an abstract method that is not
declared by one of the decorated types, a definition error results
* All abstract methods have a container-generated implementation
that simply delegates the method call to the delegate object
With this definition, I don't think we need any special-casing for
abstract methods annotated @Inject, @PostConstruct, etc.
++ Clarify that scope types should not have members
The spec should mention that @ScopeType annotations should not have
annotation members. Perhaps this should be a definition error.
javax.inject.Scope already mentions this.
++ Clarify that parameters of producer and disposer methods are
injection points of the producer method bean
We say that "....parameters are injection points." We should be
clearer and say "....parameters are injection points of the producer
method bean."
++ Clarify that not all classes in a bean archive are bean classes
We should be clearer and say that you can put non-bean classes (e.g.
MDBs) in a bean archive.
++ Clarify that there can be multiple AnnotatedType instances per Java class
This is not 100% clear in the spec.
++ Clarify that interceptors/decorators don't apply to producers in
resolution rules
We say this in the preamble, but we should also mention it in the
resolution rules.
++ In lifecycle chapter, clarify creation of interceptors/decorators
Not sure precisely what we need to say, but the note in 11.2 is not
sufficient, I think.
++ Producers and beans that are under construction
I think we need the spec to say something about cases where an
injection point of a bean resolves to a producer method of the same
bean. The implementation should detect that this is a definition
error. It shouldn't try to call a producer method on a
non-fully-initialized bean.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
14 years, 11 months
Any plans for a weld-user ist?
by Johan Eltes
It would be great me and other users to get a weld-user list!
My major pain is to wrap my head around how to implement junit tests for cdi beans.
Having a place where users could get together to sort out essential issues for projects trying to use Weld, would be great. If anyone has a sample of a unit test that does not depend on anything else than weld 1.0.0 would be really great:
- How to have the test target object injected into the test case ?
... or...
- How to obtain an injected test target object from within the test case?
/Johan
14 years, 12 months
TCK Run with custom-web.xml
by Gurkan Erdogdu
Hi;
I have created a custom-web.xml according to package structure org/jboss/testharness/impl/packaging/war/custom-web.xml. But when I run LongRunningConversationPropagatedByFacesContextTest, it deploys with web.xml that is not custom-web.xml.
According to the code, WarArtifactDescriptor, it must honor custom-web.xml
What is wrong? And also what is the meaning of @IntegrationTest(local=true) ?
Thanks;
--Gurkan
___________________________________________________________________
Yahoo! Türkiye açıldı! http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
14 years, 12 months
Re: [weld-dev] Non flat deployments
by Ales Justin
> Probably the easiest way to address this is simply to mirror the
> classloading structure of war and ears in JBoss AS.
Perhaps I'll try to come up with something quickly for standard JEE
deployments, where CL structure is simple and well known.
But eventually we should have proper generic CL mapping.
e.g. when users use jboss-classloading.xml or OSGi
> * remember that we also need to access "installed
> libraries" - those things libraries installed in the AS. So IOW we
> need to have a list of all libraries which have beans.xml in them,
> and add them to each CDI deployment, so that libraries, modules in
> the deployment can see them but not vice-versa.
What's an "installed library"?
How do we track/recognize them?
e.g. "installed library" vs. normal CDI deployment
14 years, 12 months
SPI enhancements
by Gavin King
So, once we started actually writing portable extensions, and seeing
the kind of crazy things people are trying to do with Weld, a couple
of missing features have popped up. I expected this, since the SPI was
the bit that had by far the least review when we were writing the
spec. The good news is that I've only found one thing we actually did
wrong (using the bean Class for determining inter-module
accessibility, instead of introducing a proper Module object). The
other things are really just missing features that can be easily
added.
I've compiled a list here:
http://www.seamframework.org/Weld/PortableExtensionWishlist
I would love to be able to roll as much of this stuff as possible into
the maintenance release, to get it out there before people start
writing portable extensions in earnest, and have to start worrying
about differences between the 1.0 and 1.1 SPIs. So I want to hear from
you guys if you think that's a reasonable thing to do. The first 4 or
5 items on this list are sorely needed.
Note that this is just part of a more extensive list of enhancements here:
http://www.seamframework.org/Weld/CDIWishlist
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
15 years
Generic beans
by Gavin King
OK, so I had a great idea today. If we can successfully implement this
as a portable extension, it should form the foundation of a lot of
stuff we implement in Seam3 (for example, Drools, JMS and JPA
integration).
Take a look at this:
http://www.seamframework.org/Weld/PortableExtensionsPackage#H-GenericBeans
Would someone please look into exactly how hard this is to implement
on the CDI 1.0 SPI? I think it's possible, though we might end up with
some annoying limitations.
I think this can *really* clean up the configuration of things like
persistence contexts, JMS sessions, Drools rule bases, etc. Now,
instead of several entries in an XML file, the user just writes a
single producer field declaration. It also dramatically simplifies the
implementation of this kind of PE.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
15 years
Weld functional tests
by Karel Piwko
Hi all,
there is QA proposal of integrating functional tests into Maven
lifecycle for building weld/seam-examples:
1/ Add an profile "ftest" into pom.xml of weld-examples-parent.
This profile contains all the necessary build executions
(starting container/deploying/running Selenium/
collecting results/undeploying/stopping container),
so this can be shared by examples.
2/ In a example, add the same "ftest" profile with dependency on
ftest-example artifact. This dependency is interval based, so
there is no need to release the example when its ftest changes.
Then add the testsuite for container into src/test/ directory of
example.
3/ Running maven with ftest profile will execute functional tests during
integration-test phase
So, all ftests are maven artifacts, downloaded from repository when
needed, normal build is untouched. We implemented this proposal for
Weld jsf/numberguess example and things are working fine.
There are currently two problems :
a/ Although weld-examples-parent contains ftest profile, this cannot be
used to recursively test all modules, because there is no way how
selectively activate this profile only for modules where this
is applicable (will be working in Maven 3). This shouldn't be the
problem, because in the end examples will be mainly parts of
weld|seam-modules, so this couldn't be used as well.
b/ User is required to pass reference to ftest.properties file with
-Dftest.properties, but this file is not a part of example
distribution. We can add this file or its skeleton to each example,
but it doesn't seem right.
And one open question:
Where will these ftest-examples packages live in SVN repository? I
placed them for the moment into examples/tests, but there might be a
better place.
Any comments on this?
Karel
15 years
