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-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
14 years, 1 month
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 ;-)
14 years, 1 month
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
14 years, 1 month
