Current WELD trunk Incontainer testing status
by Martin Gencur
There are results from yesterday (2009-02-17) on Linux machine in
Hudson:
---------Weld Core Tests-----------
Tests run: 231, Failures: 6, Errors: 0, Skipped: 0, Time elapsed:
429.714 sec <<< FAILURE!
Results :
Failed tests:
testAlternativesOnProducers(org.jboss.weld.tests.alternatives.AlternativesTest)
testDetectsJsf12Version(org.jboss.weld.tests.jsf.JsfApiAbstractionTest)
testLoadsJsf12Classes(org.jboss.weld.tests.jsf.JsfApiAbstractionTest)
testLoadsJsf20Classes(org.jboss.weld.tests.jsf.JsfApiAbstractionTest)
testGetNamedBeanWithBinding(org.jboss.weld.tests.resolution.named.NamedBeanTest)
testNamedInjectedFieldUsesFieldName(org.jboss.weld.tests.resolution.named.NamedBeanTest)
--------CDI TCK runner for Weld---------
Tests run: 791, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 1,490.474 sec <<< FAILURE!
Results :
Failed tests:
testApplicationScopeActiveDuringCallToEjbTimeoutMethod(org.jboss.jsr299.tck.tests.context.application.ejb.EJBApplicationContextTest)
testSingletonWithConversationScopeFails(org.jboss.jsr299.tck.tests.implementation.enterprise.broken.singletonWithConversationScope.SingletonWithConversationScopeTest)
All the other tests passed.
16 years
Injection into servlets, filters etc. for Jetty
by Matija Mazi
Hi,
I've done some work on injection into servlets and filters for Jetty 6. Here's what I've come up with so far – the patch (to be applied to weld/servlet/trunk) is attached; I'll also attach it to the Jira issue (https://jira.jboss.org/jira/browse/WELDX-23).
This includes injection into Servlets and Filters, but not Listeners. It adds a sub-module weld-jetty-support to the weld-servlet module and changes some stuff in the weld-servlet-int module. To use it you need to:
- add weld-jetty-support.jar to JETTY_HOME/lib
- package the new weld-servlet.jar with your war/WEB-INF/lib (as normally)
- deploy your web app into Jetty
- change the attached myapp-context.xml to refer to your web app and deploy it into JETTY_HOME/contexts
Here are some open issues that remain and need some discussion. Which of these should I work on first?
1. Injection into Listeners. As far as I could see, this isn't yet supported even in Tomcat? I've done some work on this for Jetty 6 (not yet included in the attached patch) and I think it can be done (using javassist to add the injection code into the first lifecycle method called on the listener).
2. I don't like the fact that you need to deploy two files into Jetty, the war and the contexts/*.xml, but I don't think there's another way since the jetty example for using annotation injection does the same.
3. I haven't provided any tests for Jetty integration. There is a jboss-test-harness-tomcat but nothing similar for Jetty. Maybe I could create a jboss-test-harness-jetty and use it to create Weld-Jetty integration tests.
4. This works for Jetty 6; I haven't tried Jetty 7.
5. I didn't do for Jetty anything similar to JspInitialization (supposed to replace the el.ExpressionFactory) in tomcat-support; how is this used?
6. Servlet injection doesn't work in Tomcat 7 (https://jira.jboss.org/jira/browse/WELDX-45); I think I should be able to fix this easily now.
Regards,
Matija
16 years
spec question on 3.5 Resource Beans
by Mark Struberg
Hi!
I don't get it if section 3.5 is only meant as an example on how to map between e.g. a named persistence unit to a @Qualifier defined injection, or if this is now the ONLY way to inject @PersistenceUnits, etc.
In the older versions of the spec it was explicitly defined that (at least in an EE environment) normal injections defined in JSR-250 et al must be supported, e.g.:
private @PersistenceContext(unitName="myUnit") EntityManager myUnitEm;
private @Ressource(lookup="java:global/env/jdbc/CustomerDatasource") Datasource customerDs;
have been perfectly valid and functional in older spec versions.
Is this still allowed/has to be supported (in an EE environment)? Argument for this: "A resource MAY be declared by..."
Or will writing this annotations (without @Produces!) into a bean will not cause any injection by a JSR-299 container?
In case of injecting @PersistenceContext, adding @Produces and a Qualifier imho simply makes them a producer field, so I don't understand why there is any need for a special 'resource bean' in this case. I also do not understand the restriction for disallowing @Named. Of course @Named in the EL sense doesn't make much sense for _any_ @Dependent scoped bean, but @Named is a perfectly valid qualifier also! So it would be perfectly valid to write
private @Inject @Named("specialEm") EntityManager em;
It would also be perfectly possible to provide a EntityManager via a producer method btw, isn't?
Is there any reason why we cannot simply say that injecting EE resources must be provided in an EE container? Then all your neat tricks should simply just work?
txs 4 clarifying,
strub
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
16 years
Passivating Capabilities check.
by Mark Struberg
Hi!
I'm just curious how Weld manages to inject a Logger into a @SessionScoped (passivating!) bean.
In your example in 1.3.5 you wrote:
>class Loggers {
> @Produces Logger getLogger(InjectionPoint injectionPoint) {
> return Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getSimpleName() );
> }
>}
and
>@SessionScoped
>public class Permissions implements Serializable {
> @Inject Logger log;
> ...
but the Logger I know are actually not Serializable themselfs and since it is @Dependent scoped, we also don't use a proxy for it.
I'd expected a DeploymentException thrown at startup in this case, but Weld actually seems to only checks passivation stuff for NormalBeans. Anyway, once the session get's passivated, you'll see a fine NotSerializableException.
Have I missed something?
txs and LieGrue,
strub
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
16 years
[TCK] About Standalone Tests
by Gurkan Erdogdu
Hi;
When TCK is run in standalone method, it still runs EJB related tests, for example org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest, SingletonWithRequestScopeTest etc.
Is it possible to annotated those EJB related tests with @IntegrationTest annotation? Therefore it will not run in standalone mode with selector TestNG DisableIntegrationTestsMethodSelector.
Thanks;
--Gurkan
___________________________________________________________________
Yahoo! Türkiye açıldı! http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
16 years
Question regarding behavior of Decorated dependent scoped beans
by Joseph Bergmark
While verifying the behavior of decorated dependent scoped beans on
OpenWebBeans, Gurkan mentioned that he observed the same behavior on WELD.
While verifying myself I noticed two behaviors that seem to conflict with
the spec.
1) Non-normal scoped beans don't have any restrictions on public fields. A
quick test showed that changes made to public fields directly are not
reflected when a call to a getter method that returns that value of the
public field is made. Presumably this is because there is an proxy like
object in the middle.
For example
@Inject MyBean myBean;
myBean.number = 7;
myBean.getNumber(); //would return the default value for number and not 7
which it was just set to.
2) Non-normal scoped beans don't require a public no-args constructor. If
the dependent scoped bean instead had a constructor annotated with @Inject
(as per 3.1.1), an InstantiationException was thrown.
Are these expected restrictions once that dependent scoped bean is
Decorated?
Sincerely,
Joe
16 years
Instance, @Produces, and InjectionPoint
by Jordan Ganoff
The InjectionPoint passed to the producer method as a result of calling
Instance.get() returns null for getAnnotated(), getBean(),getMember(), and
has no qualifiers (regardless of whether the declaration defined them or
not). Is this the intended behavior when injecting Instances for
programmatic lookup via Instance.get()?
I'm using Arquillian's jboss-remote-60 profile and haven't had any problems
other than with Instance thus far. Here's a sample of what I'm talking
about:
Test.java:
@Inject @Destination Instance<Topic> t;
@Test
public void testInjection()
{
assertNotNull(t.get());
}
TopicProducer.java:
@Produces @Destination
public Topic getTopic(InjectionPoint ip) { ... }
--
Jordan Ganoff
16 years
PassivationCapable question
by Mark Struberg
Hi!
Section 6.6 states that
>A bean is called passivation capable if the container is able to temporarily
> transfer the state of any idle instance to secondary storage.
To me it is still not always clear if the term bean is now solely meant as terminus technicus for Bean<T> or if it's still sometimes used for it's contextual intances.
For the sentence above: does 'bean ... any idle instance' mean that it's in question whether the Bean<T> is serializable or it's contextual instances shall be?
As far as I've seen in the RI sources, the interface PassivationCapable has nothing to do with your 'passivation capable' criteria used throughout 6.6 since RIBean implements PassivationCapable indicates that all your internal beans are passivation capable. Instead you have internal functions to handle that. But how do portable extensions (like a custom context implementation) access this information?
txs 4 clarifying,
strub
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
16 years
