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, 2 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.
13 years, 8 months
[ANN] Perf4CDI - Perf4j integration for CDI
by Marcin Zajączkowski
Hi,
I would like to announce release of the initial version of Perf4CDI [1]
- Perf4j integration for CDI based applications.
Perf4j is a performance monitoring library for Java applications which
allows to simple measure methods/blocks' execution time (e.g. using one
annotation and AOP). Perf4CDI brings that ability to CDI based applications.
Perf4CDI should be compatible with every CDI implementation and was
successfully tested with OpenWebBeans 1.0.0-M4. Due to WELD-507 [2] the
first supported Weld version will be probably 1.0.2.CR1.
This is the initial release (0.3.0), but Perf4CDI is a sister project of
Seam-Perf4j [3] which supports Seam Framework 2.2.x and works fine in
that environment for awhile.
If you have questions or suggestions about Perf4CDI please ask here or
on Perf4j's discussion mailing list [3].
[1] - http://perf4cdi.sourceforge.net/
[2] - https://jira.jboss.org/browse/WELD-507
[3] - http://perf4cdi.sourceforge.net/support.php#discussion
Regards
Marcin Zajączkowski
13 years, 12 months
All tests passing
by Pete Muir
Team,
All tests for Weld are now passing, both standalone and incontainer.
Thanks to David (for fixing the proxies), Marius, and Aslak (for
converting the core integration tests to Arquillian), we are now in a
good place to move forward.
We will aim to release 1.1.0.Beta1 towards the end of next week, or
early the following - so that we can integrate this into JBoss AS and
GlassFish.
Pete
--
Pete Muir
http://in.relation.to/Bloggers/Pete
http://www.seamframework.org
14 years
Converting Weld Core Tests to Arquillian
by Aslak Knutsen
I'm in the process of converting/moving a lot of the tests in
core/test over to core/tests-arquillian.
Both modules will be unstable for a little while.
I'll give a new shout when done..
-aslak-
14 years
Lack of org.jboss.weld.weld-core-test dependencies in Maven Central Repository
by Marcin Zajączkowski
Hi,
Some time ago I had some problems to put Seam-Perf4j to the Maven
Central Repository due to lack of Seam 2.2.x dependencies in MCR.
Recently I've made Perf4CDI and I was happy that it can be built using
default Maven configuration. Recently I tried to built it from some
external server I've noticed that weld-core-test (which was added in the
latest release to simplify unit testing) has a lot of dependencies which
are not available in MCR:
org.jboss.interceptor:jboss-interceptor:jar:1.0.0-CR11
org.glassfish.web:el-impl:jar:2.1.2-b04
org.jboss.ejb3:jboss-ejb3-api:jar:3.1.0
javassist:javassist:jar:3.11.0.GA
javax.faces:jsf-api:jar:2.0.2-FCS
javax.el:el-api:jar:2.2
org.jboss.test-harness:jboss-test-harness:jar:1.1.0-CR5
I've read that there are changes in a structure of JBoss' repositories
and my question is when is it planned to move/sync Weld (test)
dependencies to Maven Central Repository?
Regards
Marcin
14 years
Problem with getInheritedInterceptionBindingTypes() in mock test
by Marcin Zajączkowski
Hello again,
After some complications I was able to set up mock tests for my
interceptor, but I have one question. Test taken from
SimpleInterceptorTest.testInterceptorModel dosn't work with my interceptor.
@Artifact
@BeansXml("beans.xml")
public class Perf4jProfiledInterceptorTest extends AbstractWeldTest {
@Test
public void testInterceptorModel()
{
InterceptorBindingModel<Perf4jProfiled> interceptorBindingModel
= new
InterceptorBindingModel<Perf4jProfiled>(Perf4jProfiled.class, new
ClassTransformer(new TypeStore()));
Set<Annotation> annotations =
interceptorBindingModel.getInheritedInterceptionBindingTypes();
Assert.assertTrue(annotations.size() != 0);
}
}
It's not a big problem for me, but
getInheritedInterceptionBindingTypes() returns empty set. I looked into
code of using classes and I suspect that something is not initialized. I
curious what I did wrong?
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@InterceptorBinding
public @interface Perf4jProfiled {
}
Proper beans.xml has my interceptor defined.
Regards
Marcin
14 years
Lack of org.jboss.weld.weld-core-test dependencies in Maven Central Repository
by Marcin Zajączkowski
Hi,
Some time ago I had some problems to put Seam-Perf4j to the Maven
Central Repository due to lack of Seam 2.2.x dependencies in MCR.
Recently I've made Perf4CDI and I was happy that it can be built using
default Maven configuration. Recently I tried to built it from some
external server I've noticed that weld-core-test (which was added in the
latest release to simplify unit testing) has a lot of dependencies which
are not available in MCR:
org.jboss.interceptor:jboss-interceptor:jar:1.0.0-CR11
org.glassfish.web:el-impl:jar:2.1.2-b04
org.jboss.ejb3:jboss-ejb3-api:jar:3.1.0
javassist:javassist:jar:3.11.0.GA
javax.faces:jsf-api:jar:2.0.2-FCS
javax.el:el-api:jar:2.2
org.jboss.test-harness:jboss-test-harness:jar:1.1.0-CR5
I've read that there are changes in a structure of JBoss' repositories
and my question is when is it planned to move/sync Weld (test)
dependencies to Maven Central Repository?
Regards
Marcin
14 years
Bean created twice
by Arun Gupta
For the attached simple application (WAR and source), accessing
http://localhost:8080/HelloConversation/faces/index.xhtml creates
ShoppingCart twice. Any idea ?
Utility class is ...
@Named("util")
@ConversationScoped
public class ConvUtil implements Serializable {
@Inject ShoppingCart cart;
public ShoppingCart getCart() {
return cart;
}
}
index.xhtml has ...
<h:inputText value="#{util.cart}" title="name" id="name"
required="true" />
ShoppingCart is ...
@Named
@ConversationScoped
public class ShoppingCart implements Serializable {
public ShoppingCart() {
System.out.println("Creating shopping cart ..." +
Calendar.getInstance().get(Calendar.MILLISECOND));
}
}
At least the log messages like:
INFO: Creating shopping cart ...264
INFO: Creating shopping cart ...265
are printed.
Tried changing the scope of ShoppingCart to RequestScoped but still the
same. Changed @Named to @javax.faces.bean.ManagedBean on ShoppingCart.
What am I not doing correctly ?
-Arun
--
Blog: http://blogs.sun.com/arungupta
Twitter: http://twitter.com/arungupta
14 years
