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
13 years, 7 months
CODI and JBoss AS 6 final: ProjectStageActivationExtension didn't implement the Extension interface
by Michael Schütz
Hi to all,
would like to run CODI/MyFaces example within JBoss AS 6 final.
Getting:
WeldBootstrapBean state=Create: java.lang.RuntimeException: Service class or
g.apache.myfaces.extensions.cdi.core.impl.projectstage.ProjectStageActivationExtension
didn't implement the Extension interface
at org.jboss.weld.util.ServiceLoader.loadClass(ServiceLoader.java:261)
[:6.0.0.Final]
at org.jboss.weld.util.ServiceLoader.loadService(ServiceLoader.java:233)
[:6.0.0.Final]
at org.jboss.weld.util.ServiceLoader.loadServiceFile(ServiceLoader.java:194)
[:6.0.0.Final]
at org.jboss.weld.util.ServiceLoader.reload(ServiceLoader.java:157)
[:6.0.0.Final]
at org.jboss.weld.util.ServiceLoader.iterator(ServiceLoader.java:346)
[:6.0.0.Final]
at org.jboss.weld.bootstrap.ExtensionBeanDeployer.addExtensions(ExtensionBeanDeployer.java:93)
[:6.0.0.Final]
at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:333)
[:6.0.0.Final]
at org.jboss.weld.integration.deployer.env.helpers.BootstrapBean.boot(BootstrapBean.java:92)
[:6.0.0.Final]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[:1.6.0_21]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[:1.6.0_21]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[:1.6.0_21]
Everything runs fine within Tomcat7.
Already posted question at Weld forum without having much success:
http://seamframework.org/Community/CODIAndJBossAS6FinalProjectStageActiva...
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
Michael
14 years, 11 months
Re: [weld-dev] JSF + CDI: @Named diff behaviour than @ManagedBean
by Dan Allen
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
technologies).
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
and developers.
On Dec 21, 2010 5:48 AM, "Sebastian E. Ovide" <sebastian.ovide(a)gmail.com>
wrote:
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 <
sebastian.ovide(a)gmail.com> wrote:
>
> no. It...
--
Sebastian E. Ovide
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
15 years
JSF + CDI: @Named diff behaviour than @ManagedBean
by Sebastian E. Ovide
Hi All,
I have just started a new project using the maven archetype
weld-jsf-jee-minimal
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
15 years
Re: [weld-dev] Weld Reference Guide 1.1 now in Flies
by Pete Muir
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!
Pete
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.
>
>
> https://translate.jboss.org/flies/project/view/weld-ref-guide
>
> http://www.seamframework.org/Weld/TranslatingWeldIntoYourOwnLanguage
>
>
> --
> Sean Flanigan
>
> Senior Software Engineer
> Engineering - Internationalisation
> Red Hat
>
15 years
Is @Specializes transitive?
by Mark Struberg
Hi folks!
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 CodiConfig
@Specializes
class Jsf1CodiConfig extends CodiConfig
@Specializes
class Jsf2CodiConfig extends Jsf1CodiConfig
If I
@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,
strub
15 years
Automatic non contextual injection using bytecode instrumentation
by Stuart Douglas
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:
@AutoInject
public class AccountService
{
private final Account account;
@Inject
private PaymentProcessor paymentProcessor;
AccountService(Account account)
{
this.account = account;
}
public void doPayment(double amount)
{
paymentProcessor.processPayment(account, amount);
}
}
We could then create the object using new and the fields will still be injected:
AccountService a = new AccountService(account);
a.doPayment(10);
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?
Stuart
15 years
Compiling against JSF 2 API
by Pete Muir
All
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?
Thanks
15 years
Weld Extensions to become Seam Solder
by Dan Allen
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
JIRA: http://jira.jboss.org/browse/SOLDER
We'd like to get a release out asap. However, before we do, we should fix
any critical issues. Send your pull requests :)
-Dan
--
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
15 years
