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, 7 months
Need Help
by geschtli
Hello
I'm can't resolve a problem with weld.
I have some beens, they are all called in this manner,
@Named("myBean")
@SessionScoped
@Stateful
public class MyBean implements Serializable
No one has a transient object.
All is working good, how long the beans are not passivated.
After that, they cannot be reactivated and the application crashes
with an weld proxie ClassCastException.
Must the user than after bean passivation do an explizit jndi lookup?
--
View this message in context: http://weld-development-discussions.46994.n3.nabble.com/Need-Help-tp29895...
Sent from the Weld development discussions mailing list archive at Nabble.com.
13 years, 6 months
TCK-style testing for Seam Cron Module
by Pete Royle
Hi,
The Seam Cron module has many providers and I'd like to test each
provider by reusing the same test suite (Arquillian), but just having a
different provider on the classpath . Kind of TCK style I think.
So I would have several provider projects, plus a tck project containing
all the common test classes. I guess then each provider project would
depend on the tck (scope: test) so that the tck tests, plus any of its
own unit tests are all run during that provider's test phase.
My concerns with this so far are:
1. I think I will need a test suite with the test classes in
src/main/java (rather than src/test/java) so that the provider can get
those classes onto its own classpath during testing. Will Arquillian
work OK like that (ie: does it have maven integration which specifically
looks under src/test/java only)?
2. The classes in the test suite have a hard-coded @Deployment, and I'm
not sure how I'd go about customising that place a different provider
class on the classpath. I don't want to have to force my providers to
extend every test case just to customise the deployment.
3. Am I going about this all wrong?
Cheers for any advice you can give me.
Pete R
13 years, 6 months
Re: [weld-dev] [cdi-dev] Shared dependent instance injection with circular reference through decorator
by Pete Muir
Move to Weld-dev as this is a bug in Weld, not the spec.
Yes, I can reproduce, can you file a WELD issue please?
On 24 May 2011, at 17:54, Christian Bauer wrote:
> import org.jboss.weld.environment.se.Weld;
> import org.jboss.weld.environment.se.WeldContainer;
>
> import javax.annotation.PostConstruct;
> import javax.decorator.Decorator;
> import javax.decorator.Delegate;
> import javax.enterprise.inject.Any;
> import javax.inject.Inject;
> import javax.inject.Singleton;
>
> @Singleton
> public class TestDecoratorInjection {
>
> public static final Weld weld = new Weld();
> public static final WeldContainer weldContainer = weld.initialize();
>
> public static void main(final String[] args) throws Exception {
> weldContainer.instance().select(TestDecoratorInjection.class).get().test();
> }
>
> @Inject
> Foo foo; // Dependent instance of TestDecoratorInjection
>
> void test() {
> foo.test();
> }
>
> public static class Foo {
>
> @PostConstruct
> void init() {
> System.out.println("INIT FOO");
> }
>
> @Inject
> Bar bar; // Dependent instance of Foo
>
> void print() {
> System.out.println("FOO");
> }
>
> void test() {
> bar.print();
> }
> }
>
> public static interface Bar {
> void print();
> }
>
> public static class BarImpl implements Bar {
> @Override
> public void print() {
> System.out.println("Bar");
> }
> }
>
> @Decorator
> public static abstract class BarDecorator implements Bar {
>
> @Inject
> @Delegate
> @Any
> Bar delegate;
>
> @Inject
> Foo foo; // Dependent instance of what?!
>
> @Override
> public void print() {
> foo.print();
> }
> }
> }
13 years, 7 months
Overly restrictive serialization requirements
by David Blevins
I find CDI 1.0 section 6.6.4 and some of the TCK tests a little confusing. I know serialization like the back of my hand and much of that section does not line up with actual serialization requirements.
The bottom line is that you can't statically check a class's serialization capabilities. Non-serializable object reference types are ok. Fields of java.lang.Object and other non-serialzable types are ok. The reference type does not need to be serializable, just the object at the other end of the reference needs to be serializable. Obviously you can't check that at deploy time, you need the instance. You can't even check it at runtime as there are callbacks in the Serialization API that allow the instance to control it's own serialization. If the class implements Serializable you just have to trust it will be when the time comes.
Small example: https://gist.github.com/988120
What's the point of mistrusting a class that claims to be serializable and adding CDI-specific restrictions on its fields, methods and constructor types?
-David
13 years, 7 months
WELD-862 and Seam Cron
by Peter Royle
Hi,
I'm aiming to make a release of Seam Cron available within the next two weeks. Currently there is an outstanding issue (https://issues.jboss.org/browse/WELD-862) which prevents Cron from running properly with Weld. I have been able to carry on developing Cron by testing it against OpenWebBeans, but obviously if we are to release a Seam module it should work against Weld.
It would be nice if WELD-862 could be fixed as soon a possible so that all future versions will work well with Cron.
But more importantly I also probably need to do something special in Cron so that it will work with the version of Weld already deployed in JBoss AS and Glassfish, which will contain the bug. The workaround mentioned in the bug report is to deep copy the InvocationContext. I attempted to do this by serialising and unserialising the InvocationContext but couldn't due to UnserializableExceptions. Does anyone have any advice for me about how I might be able to work around this bug to support existing versions of Weld?
Cheers,
Pete R
13 years, 7 months
org.jboss.weld.exceptions.WeldException: Not an entity
by brian
Hi,
I used seam-forge to gen a project and am attempting to replace the
beans with beans from my existing application. Getting an exception
from Weld saying that my entity isn't an entity:
I have my Entity, edu.vt.Service, annotated @Entity:
@Entity Service
---
My Session bean looks like this:
import edu.vt.Service
@Transactional @Named @Stateful @RequestScoped public class ServiceBean
extends PersistenceUtil {
private List<Service> list=null;
---
list.xhtml:
<ui:repeat var="entity" value="#{serviceBean.list}">
<li>#{entity.uid} <h:link outcome="view" value="[view]">
<f:param name="uid" value="#{entity.uid}"/>
</h:link> #{entity} </li>
</ui:repeat>
---
bean deploys fine, navigating to the 'list' page throws an exception:
16:15:46,875 ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/serviceDemo-1.0.0-SNAPSHOT].[FacesServlet]] Servlet.service() for servlet FacesServlet threw exception: java.lang.IllegalArgumentException: Not an entity: class edu.vt.Service
---
any idea what i'm doing wrong?
13 years, 7 months
tx services
by Ales Justin
IMO TransactionServices should also expose TransactionManager.
Since with AS7, which hides TM from JNDI, one cannot easily register XAResources:
Transaction
public boolean enlistResource(XAResource xaRes) throws RollbackException, IllegalStateException, SystemException
or suspending/resuming current Tx.
Specially XAResources handling is a must to be able to enlist if you're doing some non-trivial tx-based work.
This way the integration layer would make sure the TM is exposed as a CDI service.
Wdyt?
-Ales
13 years, 7 months
