[
https://jira.jboss.org/browse/WELD-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kabir Khan updated WELD-555:
----------------------------
Description:
>From Weld Dev mailing list:
--------------------------------------------
That's tricky. I'm sort of having the same problem with Spring integration.
Bean Validation requires a matching bean to exist so the only idea I can come
up with is to register a placeholder before injection actually takes place. But
that defeats the purpose of having an InjectionService (what's the use for it
if you can do the same via a custom bean).
One potential solution that I see is to allow for a ValidationService in a
similar vein to InjectionService.
On 10-06-11 11:18 AM, Kabir Khan wrote:
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:
[[email protected]()]
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
_______________________________________________
weld-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-dev
was:
>From Weld Dev mailing list:
--------------------------------------------
Hey Kabir,
Some time ago we decided to move the weld-int stuff (whatever is specific to
JBAS) into JBAS itself, for making the integration between the two a bit more
straightforward.
So the stuff that is now inside JBAS is a copy of the former weld-int project
(with the poms modified to match JBAS). I made some changes to JSF stuff and
JNDI registration.
Following a comment made by Ales, the deployer-mc-int stuff stayed in its old
location (as it is not currently packaged inside the JBAS distro), and is
mainly untouched. Since it seems to depend on other modules, it may make sense
to extract the common stuff and make it a dependency to both the JBAS weld-int
and the extraneous mc-weld-int. For now, I just made sure that the clone works,
and perhaps this is a step that is hard to complete before M4.
I think that you can use the deployer-mc-int as is for now, if you're not
affected by the current duplication issues. Or, let me know if I can help
working something out.
Marius
On 10-06-11 9:42 AM, Kabir Khan wrote:
I am about to revisit the MC/Weld integration for Ales's and my talk at JUDCon.
The work was done under
https://svn.jboss.org/repos/jbossas/projects/weld-int/trunk, more specificially
under
https://svn.jboss.org/repos/jbossas/projects/weld-int/trunk/deployer-mc-int.
Updating AS trunk now I see a new weld-int project with the following sub
directories;
assembly/
deployer/
ejb/
pom.xml/
webtier/
In https://svn.jboss.org/repos/jbossas/projects/weld-int/trunk I see
assembly/
deployer/
deployer-mc-int/
ejb/
pom.xml/
webtier/
The https://svn.jboss.org/repos/jbossas/projects/weld-int/trunk/deployer-mc-int
are working, and the next step is to try this out in AS, but I am confused how
the two locations relate to each other and where my deployer-mc-int/ stuff
should go?
Cheers,
Kabir
_______________________________________________
weld-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-dev
> Pluggable validation
> --------------------
>
> Key: WELD-555
> URL: https://jira.jboss.org/browse/WELD-555
> Project: Weld
> Issue Type: Feature Request
> Components: Weld SPI
> Reporter: Kabir Khan
>
> From Weld Dev mailing list:
> --------------------------------------------
> That's tricky. I'm sort of having the same problem with Spring integration.
> Bean Validation requires a matching bean to exist so the only idea I can come
> up with is to register a placeholder before injection actually takes place.
> But that defeats the purpose of having an InjectionService (what's the use
> for it if you can do the same via a custom bean).
> One potential solution that I see is to allow for a ValidationService in a
> similar vein to InjectionService.
> On 10-06-11 11:18 AM, Kabir Khan wrote:
> 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:
> [[email protected]()]
> 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
> _______________________________________________
> weld-dev mailing list
> [email protected]
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
weld-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-issues
