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, 6 months
Wire Compatibility
by Andrew Lee Rubinger
Hey guys:
Had a good talk w/ Dan and Lincoln at the conclusion of JBossWorld
regarding wire compatibility and was asked to pass references along to
this list.
The key is that marking a class as "implements Serializable" isn't
sufficient to:
1) Make it really Serializable
2) Ensure that the wire protocol maintains compatibility across releases
I've been using a technique documented by Bob Lee awhile back:
http://crazybob.org/2006/01/unit-testing-serialization-evolution_13.html
The idea is that after you've formalized your protocol (ie.
Externalizable or readObject/writeObject explicitly), you make a copy of
this original class. Then, using a special ObjectOutputStream, you can
redefine this class as a new name, hence converting from old to new or
new to old.
For instance, I implement this here in ShrinkWrap to make Archives
Serializable:
http://anonsvn.jboss.org/repos/common/shrinkwrap/trunk/impl-base/src/test...
Recommend this approach, or one similar. Some folks like to serialize
the original version into a .ser file which stays in SCM, and ends up
being the basis for the test point. But that can only test compat in
one direction.
S,
ALR
14 years, 4 months
Wire Compatibility
by Andrew Lee Rubinger
Hey guys:
Had a good talk w/ Dan and Lincoln at the conclusion of JBossWorld
regarding wire compatibility and was asked to pass references along to
this list.
The key is that marking a class as "implements Serializable" isn't
sufficient to:
1) Make it really Serializable
2) Ensure that the wire protocol maintains compatibility across releases
I've been using a technique documented by Bob Lee awhile back:
http://crazybob.org/2006/01/unit-testing-serialization-evolution_13.html
The idea is that after you've formalized your protocol (ie.
Externalizable or readObject/writeObject explicitly), you make a copy of
this original class. Then, using a special ObjectOutputStream, you can
redefine this class as a new name, hence converting from old to new or
new to old.
For instance, I implement this here in ShrinkWrap to make Archives
Serializable:
http://anonsvn.jboss.org/repos/common/shrinkwrap/trunk/impl-base/src/test...
Recommend this approach, or one similar. Some folks like to serialize
the original version into a .ser file which stays in SCM, and ends up
being the basis for the test point. But that can only test compat in
one direction.
S,
ALR
14 years, 4 months
Weld 1.1.0
by Pete Muir
Team,
I would like to skip the Weld 1.0.2 release, and move straight onto Weld 1.1.0. This aligns well with both the JBoss AS and GlassFish schedules. We've got a few issues that we can't satisfactorily resolve without SPI updates (like David's work on the serialization of proxies). Additionally, David's changes for this turned out to be pretty large, so I think we should bump the version number anyway.
Other work we would do that will affect containers running Weld is:
* Exposure of reflection access to the container, allowing to be swapped out (indexing/scanning)
* Switch to JBoss Logging 3
I would estimate we would then be able to accelerate the 1.1 schedule, such that we can get a beta done in early August.
Any issues others can see with this plan?
Pete
14 years, 5 months
CDI TCK: extensions.processBean.ProcessBeanTest
by Scott Ferguson
Hopefully this is the right list for CDI TCK discussions.
I'm puzzled by an assertion in extensions.processBean.ProcessBeanTest,
specifically
testProcessProducerMethodEvent()
79: assert ProcessBeanObserver.getCowShedProcessBeanCount() == 2;
testProcessProducerFieldEvent()
102: assert ProcessBeanObserver.getChickenHutchProcessBeanCount()
== 2;
But I can't see how this number is 2 instead of 1. The Cowshed looks like:
public class Cowshed {
@Produces public Cow getDaisy() { ... }
}
So there should be 3 relevant extension events fired:
ProcessBean<Cowshed>
ProcessProducerMethod<Cowshed, Cow>
ProcessBean<Cow>
I double checked the ProcessProducerMethod interface:
ProcessProducerMethod<T,X> extends ProcessBean<X>
which is where the ProcessBean<Cow> comes from, but I don't see where
the 2nd ProcessBean<Cowshed> comes from.
-- Scott
14 years, 5 months
Development stages
by Ken Finnigan
I've been thinking that we need a way to distinguish between development
or production so that we can perform extra start up checking while in
development that we wouldn't want to perform in production. It's been
suggested that we could do something similar to what has been added to
myfaces
<https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/core/api/sr...>,
to make it easier to standardise in the future.
If everyone felt it was beneficial to have a "project stage", should it
be added as a Seam module or a Weld Extension?
Ken
14 years, 5 months
MC/Weld integration Pull vs Push from MC
by Kabir Khan
The Weld/MC integration currently works via a "push" model where the MC pushes beans with the @WeldEnabled annotation so that they are usable from Weld. If I have this MC bean
@Thing
@WeldEnabled
public class ThingBean
{
}
and this Weld bean
public class ThingField
{
@Inject @Thing
public ThingBean thing;
}
Then when deployed the MC bean is made available to Weld. I do something along the lines of
---
//Set up Weld
TestContainer testContainer = new TestContainer(new MockEELifecycle(), Arrays.asList(McBeanObserver.class, ThingBean.class), null);
testContainer.getDeployment().getServices().add(InjectionServices.class, new McLookupInjectionServices()); //Adding custom injection services
testContainer.getLifecycle().initialize();
//Deploy MC bean
...
//Start up Weld
testContainer.getLifecycle().beginApplication(); //A
testContainer.ensureRequestActive();
//Get bean
Set<Bean<?>> beans = getCurrentManager().getBeans(clazz);
assertEquals(1, beans.size());
Bean<ThingBean> bean = (Bean<ThingBean>)beans.iterator().next();
CreationalContext<T> createCtx = getCurrentManager().createCreationalContext(null);
ThingBean bean = bean.create(createCtx); //B
---
This works fine. My McLookupInjectionServices bean just does some simple logging while playing around
public class McLookupInjectionServices implements InjectionServices
{
public <T> void aroundInject(InjectionContext<T> ctx)
{
System.out.println("--------> CUSTOM INJECTION SERVICES");
ctx.proceed();
}
public void cleanup()
{
}
}
and I can see it kicking in as a result of the call to B.
What I would like to do is to change what I have done so that instead of having to know in advance which MC beans should be made available to Weld, to use my McLookupInjectionServices to "pull" any beans it can not find in Weld from the Microcontainer instead. My initial attempt at this is to get rid of the @WeldEnabled annotation from the MC bean:
@Thing
@WeldEnabled
public class ThingBean
{
}
However, this falls at A, and never gets to my McLookupInjectionServices
org.jboss.weld.DeploymentException: Injection point has unstatisfied dependencies. Injection point: field org.jboss.test.kernel.weld.mctowb.support.wb.ThingField.thing; Qualifiers: [@org.jboss.test.kernel.weld.mctowb.support.mc.Thing()]
at org.jboss.weld.Validator.validateInjectionPoint(Validator.java:232)
at org.jboss.weld.Validator.validateBean(Validator.java:80)
at org.jboss.weld.Validator.validateRIBean(Validator.java:100)
at org.jboss.weld.Validator.validateBeans(Validator.java:282)
at org.jboss.weld.Validator.validateDeployment(Validator.java:268)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:389)
at org.jboss.weld.mock.MockServletLifecycle.beginApplication(MockServletLifecycle.java:105)
This ends up in TypeSafeResolver
public Set<T> resolve(Resolvable key)
{
final MatchingResolvable resolvable = MatchingResolvable.of(transform(key));
Callable<Set<T>> callable = new Callable<Set<T>>()
{
public Set<T> call() throws Exception
{
return sortResult(filterResult(findMatching(resolvable)));
}
};
Set<T> beans = resolved.putIfAbsent(resolvable, callable);
return Collections.unmodifiableSet(beans);
}
but I don't see any way to make this pluggable so that it can check the MC? Is there such functionality, and if not would it be possible to add it? The idea being that I could do
public <T> void aroundInject(InjectionContext<T> ctx)
{
System.out.println("--------> CUSTOM INJECTION SERVICES");
ctx.proceed();
//Iterate over ctx.getInjectionTarget().getInjectionPoints() and find the unresolved ones
}
Although, I don't know if there is anything there to see if an injection point has been injected either?
Cheers,
Kabir
14 years, 5 months
@User global qualifier
by Ken Finnigan
All,
In the Seam i18n module we have @UserTimeZone and @UserLocale to
distinguish between application and user TimeZone or Locale instances
that are produced.
Given the name of these qualifiers also includes the type, it has
become apparent that this is both wordy and unnecessary.
As such, what are everyones thoughts on adding @User to Weld
Extensions that can then be utilised within all Seam modules for
similar purposes?
Regards
Ken
Sent from my iPhone
14 years, 5 months
