Adding Classes at Run-time
by Jason Lee
I have an odd question. I have a situation where I'm manually opening a
JAR and adding its classes to the ClassLoader. What I'd like to be able
to do is have Weld scan these classes for any relevant annotations and
take the proper actions, just as if the JARs were in the classpath when
the application started. I've been staring at the JavaDocs (build
locally, btw, as I can't find them on the web :| ) but I don't see any
way to request that Weld inspect a given class. Is it there and I'm
missing it? Am I going to have cobble together that functionality? Am
I asking for something that can't be done (right now)? Any nudges in
the right direction would be much appreciated. :)
--
Jason Lee, SCJP
President, Oklahoma City Java Users Group
Senior Java Developer, Sun Microsystems
http://blogs.steeplesoft.com
12 years, 6 months
Use of "to" and "from" when refering to assignments in section 5.2.3
by Bill Wigger
In section 5.2.3 the spec seems to be misworded with respsect to "assignable
to" and "assignable from".
The start of this section states (capitalization addded):
"A parameterized BEAN TYPE is considered ASSIGNABLE TO a parameterized
REQUIRED TYPE if they have identical raw type and for each parameter:"
and then it list as one of the cases:
"the REQUIRED TYPE parameter is an ACTUAL TYPE, the BEAN TYPE parameter is a
TYPE VARIABLE and the ACTUAL TYPE is ASSIGNABLE TO the upper bound, if any,
of the TYPE VARIABLE"
This seems to state that a Bean Type is assignable to a Required Type if ...
the Required type is assignable to the upper bound of the Bean Type. This
seems to then be contradicting itself, and the reading of that second part
should be:
"the required type parameter is an actual type, the bean type parameter is a
type variable and the actual type is ASSIGNABLE FROM the upper bound, if
any, of the type variable"
The question comes down which injection below is valid:
public class C1<T extends MediumClass> {
@Produces ... ArrayList<T> m1()
@Inject ... ArrayList<SmallClass> s1;
@Inject ... ArrayList<BigClass> b1;
where
MediumClass extends SmallClass
and
BigClass extends MediumClass
Seems like the injection using SmallClass should work, since what is
produced will be a MediumClass which will have all the methods needed by
SmallClass.
And the injection using BigClass should fail, since what is produced will be
a MediumClass which will not have all the methods needed by BigClass.
But, according to the spec (and what seems to be enforced by the TCK) is
that since Required Type (in this case SmallClass and BigClass), must be
assignable TO the Bean Type (Medium Class), therefore the BigClass
assignment is the one that works, since BigClass is assignable TO
MediumClass. But since MediumClass doesn't have all the methods that
BigClass has, then what is
produced will be insufficient for the injection.
So, is the spec misworded here? Which of these injections should be
resolved, and which one should give an error?
Bill W.
14 years
Weld 1.1.0.Beta1
by Pete Muir
http://in.relation.to/Bloggers/Weld110Beta1
Thanks again to everyone who helped out with this release!
Now, onwards to Beta2, where we are focusing on:
* solid cluster support (primarily this means getting some good testing in place)
* performance and scalability improvements
* exposing the reflection layer via the SPI, and altering the bootstrap to allow this to be cached by the container (first place this will see light is likely JBoss AS 7)
* bug fixing around conversation support, and exposing the ConversationManager API
Pete
14 years, 2 months
jsf/examples - functional tests
by Martin Gencur
Hello all,
I would like to inform you that there are functional tests for
JSF examples in Weld core. Basically, they are able to test
web interface and thus functionality of individual examples.
You can run them to verify that nothing was broken. We'll also
prepare hudson job which will run them periodically. A simple
tutorial for running the functional tests can be found in
examples/readme.txt. You just start JBossAS 6 and then run a
command like the following in the examples directory:
mvn -Pftest-jboss-remote-6,jboss6 clean verify
There are also different containers that can be used. Just read the
readme.txt
--
Seam QA Team
14 years, 3 months
Weld Integration Tests
by Pete Muir
Team,
If you spot a test in the Weld integration test suite (arquillian-tests), either testing for a regression or otherwise, which is testing an assertion from the spec, please make a short // TODO note, stating that the test should move to the CDI TCK 1.1 and where the assertion is in the spec. This will make fleshing out the TCK 1.1 much easier :-)
Thanks!
14 years, 3 months
CDI TCK 1.0.2 CR2 released
by Pete Muir
All,
I have tagged the 1.0.2 release candidate 2, and pushed it to the JBoss Maven repository. I will upload the zip distro once Weld 1.1.0 Beta 1 is available.
Thanks to David, Marius for fixing issues, and Scott and Gurkan for reporting them!
Pete
14 years, 3 months
Migration to git
by Pete Muir
Team
I am moving Weld core, servlet, docs, examples and se to Git NOW.
Please hold commits until I follow up with new urls.
I will hold off moving cdi-tck and cdi-api until we aren't part way through a version (so we have some continuity of tags).
I'm not sure what people want to do with archetypes (Steven) and ftest (QA) - let me know.
Sandbox is basically legacy stuff, so I will remove it.
Pete
14 years, 3 months
