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
Hi to all,
would like to run CODI/MyFaces example within JBoss AS 6 final.
WeldBootstrapBean state=Create: java.lang.RuntimeException: Service class or
didn't implement the Extension interface
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Everything runs fine within Tomcat7.
Already posted question at Weld forum without having much success:
What I would like to know:
1) Is it not supposed to run?
2) Is it project configuration issue?
3) Is it a bug? (JBoss, Weld? JIRA issue already filed)
thanks a lot
A clarification requested. Does the generated bean proxy ever use SLF4J?
Earlier, I had added  the SLF4J api and implementation packages to
the weld-integration-fragment bundle in GlassFish that exports all the
packages that are needed for bean proxies, but I see that preventing an
application component to use their own SLF4j api or impl binding .
Removing the SLF4J packages doesn't cause any issues with my tests and I
was wondering if SLF4J is used by the generated proxy class in any
If you are using CDI, please do not use the JSF managed bean annotations
(@javax.faces.bean.*). JSF managed beans do not have any integration with
CDI because that spec was not properly aligned with the platform.
The CDI annotations give you everything you need as a drop-in replacement.
That was the original goal of CDI (it has become a lot more, thankfully).
If you are concerned that you'll accidentally use the JSF managed bean
annotations without realizing it, you can either:
- exclude the javax.faces.bean package from the allowed imports in your IDE
- use Seam Faces or MyFaces CODI, which both alias the JSF managed bean
annotations to CDI annotations (effectively intergrating the two
I strongly recommend that you checkout the Weld reference guide for more
tips on how to use CDI beans and scopes.
Hope that helps,
- Dan Allen
Sent from my Android-powered phone:
An open platform for carriers, consumers
On Dec 21, 2010 5:48 AM, "Sebastian E. Ovide" <sebastian.ovide(a)gmail.com>
adding implements Serializable fixes that exception... but now it cannot
find the methods of the managed (named) bean...
I guess that must be another way to inject CDI into JSF...
On Tue, Dec 21, 2010 at 12:43 AM, Sebastian E. Ovide <
> no. It...
Sebastian E. Ovide
weld-dev mailing list
I have just started a new project using the maven archetype
I have a Bean which has a property:
@Inject @TodoInotherway private TodoSrv todoService;
If I annotate the bean with @ManagedBean the injection fails and todoService
will be always null.. If I annotate the Bean with @Named, the property is
injected correctly but the Bean is instantiated several times for each
request even if it is annotated as @SessionScoped and therefore all it's
properties are recreated... (with @ManageBean it saves the properties for
the whole session)
Is it a bug ?
any ideas ?
Sebastian E. Ovide
Adding weld-dev to keep everyone in the loop.
Thanks Sean for your help on this.
We currently aren't releasing any translations due to the translations being largely out of date (I look for at least 50% translation to release a guide, otherwise it just is a bit odd!), so there is no freeze right now!
On 16 Dec 2010, at 07:03, Sean Flanigan wrote:
> Hi everyone,
> The Weld Reference Guide 1.1 has now been imported into Flies for
> translation, along with a copy of the 1.0 translations (just for
> reference). Thanks to Pete Muir for helping with this!
> Pete, is the reference guide frozen for translation? (I gather the
> release is very soon.) This list is probably the best place for letting
> translators know about documentation freezes.
> Sean Flanigan
> Senior Software Engineer
> Engineering - Internationalisation
> Red Hat
I have the following situation and couldn't find a _clear_ answer to my question (various hints, but as I said: not really clear):
class Jsf1CodiConfig extends CodiConfig
class Jsf2CodiConfig extends Jsf1CodiConfig
@Inject CodiConfig cc;
is it well defined in the spec that I must get Jsf2CodiConfig?
Imo it should be, but before I 'fix' this in OWB, I need an ok that this transitive behaviour is conform with the spec. And of course that Weld is behaving in the same way ;)
txs and LieGrue,
I just had an idea for something that I think would be rather cool,
and allow objects created using new to be injected automatically.
Conceptually it would look something like this:
public class AccountService
private final Account account;
private PaymentProcessor paymentProcessor;
this.account = account;
public void doPayment(double amount)
We could then create the object using new and the fields will still be injected:
AccountService a = new AccountService(account);
To implement this will require a javaagent, which will modify the
bytecode of @AutoInject annotated classes as they are loaded, so that
the constructor bytecode looks up the values to inject and sets the
injected field values appropriately. Would this be something that is
worth putting into weld extensions?
I am considering compiling Weld against the JSF 2 API. As both JBoss AS and GlassFish use JSF 2, I don't see any problems there, but wanted to see if anyone would object who is using Tomcat, Jetty or GAE?
Just to give everyone a heads up, we are in the process of renaming Weld
Extensions to Seam Solder, bringing it under the Seam 3 project banner. The
project will retain exactly the same focus as its predecessor and will
continue to be portable to any CDI implementation. It just makes the
distinction between Weld and Seam more clear.
Weld = implementing CDI
Seam 3 = extending and building on CDI (plus other goodies)
Rather than migrating all the resources, we are making a clean break (fork).
If you are adding new features or fixing issues, please do so in Seam Solder
unless there is some specific reason you are updating Weld Extensions.
All the resources can be found on the project page. For your convenience,
I've laid out the key resources here:
Project page: http://seamframework.org/Seam3/Solder
Git repo: http://github.com/seam/solder
We'd like to get a release out asap. However, before we do, we should fix
any critical issues. Send your pull requests :)
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597