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
11 years, 4 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.
12 years, 10 months
WELD-273 Add GlassFish targets to example POMs
by Marcin Mieszek
Hi,
I have made some progress with issue WELD-273. Please find diff file
attached for the first example (weld-jsf-login) and let me know if the
apporach is correct.
Originally I planned to use glassfish-embedded server, but maven
plugin does not have the option to run the server in another process
so that integration tests are not blocked by the server processing its
requests (similar thing is done with jetty and daemon parameter). I
also did not have success with cargo plugin so I switched to
glassfish-maven-plugin.
Changes description:
Defining ftest-glassfish profile:
# modified: examples/jsf/login/pom.xml
# modified: examples/pom.xml
Copy of test suite definition from jboss6x.xml. Do we really need
seperate one for each appserver?
# new file: examples/jsf/login/src/ftest/resources/glassfish3x.xml
Making the class implement Serializable interface to avoid Glassfish
deployments errors:
# modified:
examples/jsf/login/src/main/java/org/jboss/weld/examples/login/Credentials.java
Setting table name to USER_TABLE as USER is reserved word:
# modified:
examples/jsf/login/src/main/java/org/jboss/weld/examples/login/User.java
# modified: examples/jsf/login/src/main/resources/import.sql
Setting to <jta-data-source>jdbc/LoginDS</jta-data-source> so that
this is accepted by Glassfish:
# modified:
examples/jsf/login/src/main/resources/META-INF/persistence.xml
One final question:
Currently there are several apporaches toward ftest. Tomcat and JBoss
use cargo plugin while Jetty uses maven-jetty-plugin. Moreover each
profile contains the same copy of failsafe plugin configuration. Can I
simplify it somehow? How about using unified apporach to deployments?
Looking forward to feedback from you,
Marcin
12 years, 11 months
Weld 1.1.0.Beta2
by Pete Muir
We're adding in a Beta2 release, to give Siva and Marius a stable build for integrating into AS/GF. Because of this all issues which don't incorporate API/SPI change slipped to CR1, we still intend to get them done, don't worry!
Marius, as you asked how to help, we're going to need a TCK release to go along with this, and I would like to get some of the issues fixed for then -- so if you can pick any up that would very nice ;-)
12 years, 11 months
TCK 1.0.1-Final Problems
by Gurkan Erdogdu
Hello;
When running TCK 1.0.1-Final with Web Profile Enabled, I have faced some issues.
1* org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ContainerEventTest
--> ServletTestRunner servlet mapping is not correct
Must be mapped as "/*", but it is mapped as "/"
· <servlet-mapping>
· · <servlet-name>JBoss Test Harness Test Runner</servlet-name>
· · <url-pattern>/</url-pattern>
· </servlet-mapping>
Therefore tests are getting 404 from server.
2* org.jboss.jsr299.tck.tests.context.ContextTest and
org.jboss.jsr299.tck.tests.context.ContextDestroysBeansTest
"Class MyContextual implements Bean<MySessionBean>" is a session scoped bean
and must be passivation capable.
To do this, it must implement "PassivationCapable" interface. But it does not
implement it. Actually, this issue has been reported and resolved in CR2
--Gurkan
12 years, 11 months
startup beans
by Dan Allen
One of the popular features in the Seam 2 "container" is startup components
(which would be startup beans in CDI terminology). I'm trying to determine
the best way to approach this feature and where it should live (i.e., Weld X
and/or Seam 3, hence the x-post).
While it's true that EJB 3.1 supports startup beans, it unnecessarily links
them to:
- enterprise beans (my, where have we heard this before? cough transactions
cough)
- singletons
Seam 2 supports startup components that are instantiated (as in
@PostConstruct gets invoked) when the scope to which the component is bound
is activated. Supported scopes include application and session. I don't see
any reason why we can't support all (or most) scopes in Weld X/Seam 3.
At first glance, you might think about initializing @ApplicationScoped
@Startup beans in an AfterDeploymentValidation observer (the
application-scope is active at that point) [1] (also see note). That's
certainly one way to go, though perhaps jumping the gun as some other
extensions may still report a deployment error. It also doesn't address the
remaining scopes.
The better place to do eager initialization is perhaps the Seam 3 Servlet
module. This module bridges the Servlet context events to the CDI event bus,
providing the opportunity to initialize components bound to the relevant
scopes. However, my concern is that if those events fire before the CDI
implementation has started the scope, it's going to result in a
ContextNotActiveException (Nik, would you be able to provide insight into
whether this ordering issue has been address?).
I'd also like to entertain the idea of having a transient startup scope
(@ApplicationStartupScoped?). Most of the time developers employ a
application-scoped startup bean, it's doing something like seeding a
database, creating directories or some other routine that's a one time deal.
It seems like a waste to have these beans hang around long after their job
is done. In fact, I anticipate it becoming the most commonly-used scope for
startup beans.
After considering the options, it seems to me that long-term, this feature
would be more robust if it were part of the CDI specification. (Even the JSF
managed bean container supports eager bean initialization for
application-scoped beans). Or perhaps I'm missing a very straightforward way
to address it.
I'm interested in hearing your suggestions. After I get feedback about which
project/module should tackle this problem, I'll create a JIRA for it.
-Dan
[1] http://gist.github.com/635719
Note: There's another issue. BeanManager#getReference() may only return a
proxy and not instantiate the bean, meaning @PostConstruct is not yet
called. In the linked gist, I worked around this problem by invoking
toString() on the reference.
I'll mention that Resin has addressed @Startup support for managed beans:
http://caucho.com/resin-4.0/examples/ioc-binding/viewfile?file=WEB-INF/cl...
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
12 years, 11 months
Auto Reply: weld-dev Digest, Vol 29, Issue 9
by barbara.louis＠oracle.com
This is an auto-replied message. I am out of office right now. I will be back in office on Oct 19th.
Contacts for each area listed below:
JAX-WS: Jitu (Jitendra.Kotamraju(a)oracle.com)
109: Rama (Rama.Pulavarthi(a)oracle.COM)
JSF: Ed Burns (edward.burns(a)oracle.com)
CDI: Siva (Sivakumar.Thyagarajan(a)Sun.COM)
Management issues: Abhijit Kumar
Thanks,
Barbara
12 years, 11 months
