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
14 years, 3 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.
15 years, 10 months
Context Management rewrite
by Pete Muir
I have just pushed a rewrite of the Weld context management to master
- essentially you can now control the contexts by injecting them into
your classes, and calling methods to associate the context with e.g.
an Http request and then activate it etc. Tomorrow I will follow up
with improved javadocs and ref docs as well as few more tests to
validate the non-servlet conversations, the ability to change
conversations mid request and to test edge cases (primarily to ensure
that the contexts don't leak if the bean destruction fails) as well as
running the example selenium tests.
To accomodate this change in API, you will need to build AS from
https://svn.jboss.org/repos/jbossas/branches/known-good-weld-snapshot/
(note that Weld in AS trunk is unstable due to changes to Flavias work
on structured deployments right now) or download a built distro from
http://people.redhat.com/~pmuir/jboss-as-distribution-6.0.0-SNAPSHOT.zip
...
As always after such a large change, it's possible that the testsuite
didn't catch something, so shout if you see a problem.
--
Pete Muir
http://in.relation.to/Bloggers/Pete
http://www.seamframework.org
15 years, 11 months
Pull requests
by Pete Muir
Hi all
Github have just altered their pull request format (allowing us to to easily do code review there). With this in mind, the new process is:
1) Create a pull request on Github (if your fork is on github, otherwise just push to your repo)
2) Link to the pull request on the associated JIRA issue, and mark it resolved
If you don't have a JIRA issue for your change, then send me an email.
Thanks!
16 years
