[JBoss Microcontainer Development] - Weld - pull from MC
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion
"Weld - pull from MC"
To view the discussion, visit: http://community.jboss.org/message/549944#549944
--------------------------------------------------------------
I have experimented with an alternate implementation of the weld-mc integration as discussed in Boston. I still need to write more tests but wanted to let the Weld guys know where I am at.
The idea is to "pull" data from the MC in special cases, which is different from the "push" we do at the moment for MC beans annotated with @WeldEnabled. I had a look at using the InjectionServices interface, but this has the following problems:
-It does not get triggered when calling constructors
-If using a separate @McInject annotation instead of @Inject to do injection the annotated field does not appear in invocation context's injection points meaning all the fields etc. need to be parsed from invocation context's target's class (I am not sure if the target will always be non-null?)
-If using the @Inject annotation with an additional @Mc annotation (to look up the particular injection point in the MC) falls over when calling proceed(), also again a problem is that you need to iterate over all fields etc. to look for the members. This also fails in the validation phase.
As mentioned the ability to do this injection from MC is something that most Weld applications would not want to do. What I have locally now is an extra service that can handle this:
package org.jboss.temp.weld.spi;
import java.lang.annotation.Annotation;
import java.util.Iterator;
import org.jboss.weld.bootstrap.api.Service;
public interface ExternalLookupRegistryService extends Service
{
Iterable<ExternalLookup<?>> getExternalLookups();
void addExternalLookup(ExternalLookup<?> externalLookup);
boolean removeExternalLookup(Class<? extends Annotation> clazz);
}
And then a service to handle particular annotations
package org.jboss.temp.weld.spi;
import java.lang.annotation.Annotation;
import java.lang.reflect.Type;
import java.util.Set;
public interface ExternalLookup<T extends Annotation>
{
Class<T> getAnnotation();
boolean isValid(Type type, Set<Annotation> qualifiers);
Object lookupValue(Type type, Set<Annotation> qualifiers);
}
I'm hoping to be able to push these interfaces into the main spi, the temp location I am using is just while playing.
Then I have modified the Validator and Field-/ParameterInjectionPoint to look for this service when validating/injecting:
> [kabir ~/sourcecontrol/weld/core/subversion]
> $svn diff impl/src/main/java/org/jboss/weld/bootstrap/Validator.java
> Index: impl/src/main/java/org/jboss/weld/bootstrap/Validator.java
> ===================================================================
> --- impl/src/main/java/org/jboss/weld/bootstrap/Validator.java (revision 6577)
> +++ impl/src/main/java/org/jboss/weld/bootstrap/Validator.java (working copy)
> @@ -83,6 +83,8 @@
> import javax.inject.Scope;
>
> import org.jboss.interceptor.model.InterceptionModel;
> +import org.jboss.temp.weld.spi.ExternalLookup;
> +import org.jboss.temp.weld.spi.ExternalLookupRegistryService;
> import org.jboss.weld.bean.AbstractClassBean;
> import org.jboss.weld.bean.AbstractProducerBean;
> import org.jboss.weld.bean.DisposalMethod;
> @@ -288,6 +290,16 @@
> Set<?> resolvedBeans = beanManager.getBeanResolver().resolve(beanManager.getBeans(ij));
> if (!isInjectionPointSatisfied(ij, resolvedBeans, beanManager))
> {
> + ExternalLookupRegistryService service = beanManager.getServices().get(ExternalLookupRegistryService.class);
> + if (service != null)
> + {
> + for (ExternalLookup<?> lookup : service.getExternalLookups())
> + {
> + if (ij.getAnnotated().isAnnotationPresent(lookup.getAnnotation()))
> + if (lookup.isValid(ij.getType(), ij.getQualifiers()))
> + return;
> + }
> + }
> throw new DeploymentException(INJECTION_POINT_HAS_UNSATISFIED_DEPENDENCIES, ij, Arrays.toString(bindings));
> }
> if (resolvedBeans.size() > 1 && !ij.isDelegate())
>
>
>
> [kabir ~/sourcecontrol/weld/core/subversion]
> $svn diff impl/src/main/java/org/jboss/weld/injection/
> Index: impl/src/main/java/org/jboss/weld/injection/FieldInjectionPoint.java
> ===================================================================
> --- impl/src/main/java/org/jboss/weld/injection/FieldInjectionPoint.java (revision 6577)
> +++ impl/src/main/java/org/jboss/weld/injection/FieldInjectionPoint.java (working copy)
> @@ -36,6 +36,8 @@
> import javax.inject.Inject;
>
> import org.jboss.interceptor.util.InterceptionUtils;
> +import org.jboss.temp.weld.spi.ExternalLookup;
> +import org.jboss.temp.weld.spi.ExternalLookupRegistryService;
> import org.jboss.weld.exceptions.IllegalStateException;
> import org.jboss.weld.exceptions.InvalidObjectException;
> import org.jboss.weld.introspector.ForwardingWeldField;
> @@ -114,7 +116,23 @@
> // if declaringInstance is a proxy, unwrap it
> instanceToInject = InterceptionUtils.getRawInstance(declaringInstance);
> }
> - delegate().set(instanceToInject, manager.getInjectableReference(this, creationalContext));
> +
> + Object value = null;
> + ExternalLookupRegistryService service = manager.getServices().get(ExternalLookupRegistryService.class);
> + if (service != null)
> + {
> + for (ExternalLookup<?> lookup : service.getExternalLookups())
> + {
> + if (getAnnotation(lookup.getAnnotation()) != null)
> + value = lookup.lookupValue(getBaseType(), getQualifiers());
> + }
> + }
> +
> + if (value == null)
> + value = manager.getInjectableReference(this, creationalContext);
> +
> +
> + delegate().set(instanceToInject, value);
> }
> catch (IllegalArgumentException e)
> {
> Index: impl/src/main/java/org/jboss/weld/injection/ParameterInjectionPoint.java
> ===================================================================
> --- impl/src/main/java/org/jboss/weld/injection/ParameterInjectionPoint.java (revision 6577)
> +++ impl/src/main/java/org/jboss/weld/injection/ParameterInjectionPoint.java (working copy)
> @@ -35,6 +35,8 @@
> import javax.enterprise.inject.spi.Bean;
> import javax.enterprise.inject.spi.Decorator;
>
> +import org.jboss.temp.weld.spi.ExternalLookup;
> +import org.jboss.temp.weld.spi.ExternalLookupRegistryService;
> import org.jboss.weld.exceptions.IllegalStateException;
> import org.jboss.weld.exceptions.InvalidObjectException;
> import org.jboss.weld.exceptions.UnsupportedOperationException;
> @@ -119,6 +121,15 @@
> @SuppressWarnings("unchecked")
> public T getValueToInject(BeanManagerImpl manager, CreationalContext<?> creationalContext)
> {
> + ExternalLookupRegistryService service = manager.getServices().get(ExternalLookupRegistryService.class);
> + if (service != null)
> + {
> + for (ExternalLookup<?> lookup : service.getExternalLookups())
> + {
> + if (getAnnotation(lookup.getAnnotation()) != null)
> + return (T)lookup.lookupValue(getBaseType(), getQualifiers());
> + }
> + }
> return (T) manager.getInjectableReference(this, creationalContext);
> }
In my test I have this implementation of the service classes
public class TestExternalLookup implements ExternalLookup<External>
{
@Override
public boolean isValid(Type type, Set<Annotation> qualifiers)
{
if (type == Bar.class)
return true;
return false;
}
@Override
public Class<External> getAnnotation()
{
return External.class;
}
@Override
public Object lookupValue(Type type, Set<Annotation> qualifiers)
{
if (type == Bar.class)
return new BarImpl();
return null;
}
}
public class TestExternalLookupRegistryService implements ExternalLookupRegistryService
{
private Map<Class<? extends Annotation>, ExternalLookup<?>> lookups = Collections.synchronizedMap(new HashMap<Class<? extends Annotation>, ExternalLookup<?>>());
public void addExternalLookup(ExternalLookup<?> externalLookup)
{
lookups.put(externalLookup.getAnnotation(), externalLookup);
}
public Iterable<ExternalLookup<?>> getExternalLookups()
{
synchronized (lookups)
{
return new HashSet<ExternalLookup<?>>(lookups.values());
}
}
public boolean removeExternalLookup(Class<? extends Annotation> clazz)
{
return lookups.remove(clazz) != null;
}
public void cleanup()
{
lookups.clear();
}
}
I register this service with the deployment and add the TestExternalLookup to it, meaning that when I create an instance of ExternalConstructorInjected the constructor parameter is found in TestExternalLookup.
public class ExternalConstructorInjected
{
Bar bar;
@Inject
public ExternalConstructorInjected(@External Bar bar)
{
this.bar = bar;
}
}
I think Pete is on vacation, so after adding a few more tests I'll add this to a branch somewhere so that it can be included once he okays it.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549944#549944]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
Re: [jboss-dev-forums] [JBoss Portal Development] - richeffect right to left
by sandeep singh
sandeep singh [http://community.jboss.org/people/sinsand] replied to the discussion
"richeffect right to left"
To view the discussion, visit: http://community.jboss.org/message/549815#549815
--------------------------------------------------------------
hey ,
got the i answer i was looking for and here is the code to slide a input or a panel form right to left
<h:form id="form1">
<rich:panel header="Dashboard" id="layoutPanel1" styleClass="parentPanel">
<rich:panel id="layoutPanel2" style="height: 40px; left: 960px; top: 192px; position: absolute; width: 40px">
<rich:effect for="layoutPanel2" name="morphpanel1" type="Morph" params="duration:0.4"/>
<rich:effect for="inputText1" name="morphtextbox1" type="Morph" params="duration:0.4"/>
<h:graphicImage onmouseover="morphpanel1({ style: 'left:800px ; width: 200px;'}),showtextbox(),morphtextbox1({ style: 'width: 150px;'})" style="height: 30px; left: 3px; top: 0px; position: relative; width: 30px" id="filter1" value="/resources/images/find.gif"/>
<h:inputText onmouseout="morphtextbox1({ style: 'width: 0px;'}),hidetextbox(),morphpanel1({ style: 'left:960px ; width: 40px;'})" style=" display:none ; right: 0px; top: 4px; position: absolute; width: 0px" id="inputText1" />
<rich:effect for="inputText1" name="showtextbox" type="Appear" params="duration:0.1"/>
<rich:effect for="inputText1" name="hidetextbox" type="Fade" params="duration:0.1"/>
</rich:panel>
</rich:panel>
</h:form>
thanks jBoss for richfaces its quite cool and easy
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549815#549815]
Start a new discussion in JBoss Portal Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - VFS3 and symlinks
by Marko Strukelj
Marko Strukelj [http://community.jboss.org/people/mstruk] replied to the discussion
"VFS3 and symlinks"
To view the discussion, visit: http://community.jboss.org/message/549790#549790
--------------------------------------------------------------
I don't think we have any performance tests in VFS yet. I'm also not aware of any JBoss projects performance testing how-to.
So here are a few things you want to have in mind specifically for testing symlink impact on performance.
First, you'll need to create a lot of symlinks, it's best they point to different files (to avoid filesystem caches) - so maybe create one directory with randomly named files and one directory with corresponding symlinks. Put a filename as content of each file.
Then use VFS on directory containing symlinks and visitor to iterate over them, read each virtual file - check that the content matches the name.
To compare the result, test nonsymlink access - delete the temp dirs and recreate just the files again using random names. Use VFS on directory containing files.
So ... the important thing is to try and neutralize the effect of filesystem caches, although in real life situations there will be a filesystem cache so does it really make sense to avoid it while testing? It depends on what you want to measure really.
The question is how realistic scenario the described test would be - having tons of symlinks. It's actually quite unrealistic as you typically don't go create symlinks for individual files, but for whole directories, so a test where the symlinks directory is actually a symlink to files directory is more realistic, but in this case again you benefit from filesystem caches.
I'd say - just cover all the scenarios :)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549790#549790]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
[JBoss Tools Development] - How to Build JBoss Tools with Maven3
by Denis Golovin
Denis Golovin [http://community.jboss.org/people/dgolovin] created the document:
"How to Build JBoss Tools with Maven3"
To view the document, visit: http://community.jboss.org/docs/DOC-15513
--------------------------------------------------------------
Current trunk version of JBoss Tools can be built with maven 3 and make it faster and easier for everyone.
h2. Prerequisites
1. Java 1.6 SDK
2. Maven 3.beta1
3. About 6 GB of free disk space if you want to run all integration tests for (JBoss AS, Seam and Web Services Tools)
4. subversion client 1.6.X (should work with lower version as well)
h2. Environment Setup
h3. Maven and Java
Make sure your maven 3 is available by default and Java 1.6 is used.
$mvn -version
should print out something like
Apache Maven 3.0-alpha-7 (r921173; 2010-03-09 14:31:07-0800)
Java version: 1.6.0_18
Java home: /usr/lib/jvm/java-6-openjdk/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.32-22-generic-pae" arch: "i386" Family: "unix"
h3. Sources
Checkout sources from anonymous SVN like
svn co https://svn.jboss.org/repos/jbosstools/trunk jbosstools-src
This will take some time dependent on your bandwidth
h2. Build Strategies
All commands below is assuming that commands are executed in jbosstools-src folder after sources checked out as it suggested above.
There are several strategies to chose from building everything to build particular component or part of it like all plug-ins, all tests, all features, particular plugin/feature.
Target platform should be built first like
$mvn -f build/target-platform/pom.xml
If you want to just compile the modules, tests can be skipped by adding system property -Dmaven.test.skip=true and you should be able to faster verify compile issues.
h3. Build/Test Everything
Current version cannot be build without local changes because of problem with with drools component, so to go with this scenario you need to remove drools references from pom.xml and site/site.xml. After that to build/test everything use:
$mvn clean install
h3. Build/Test Particular Component with Dependencies
For convenience there are aggregator projects defined for each component. It provides a simple way to build/test components with dependencies.
$mvn clean install -f build/component/${component.name}.xml
where ${component.name} is component you want to build/test. Currently build/component folder contains aggregator projects for:
1. tests
2. jmx
3. archives
4. as
5. common
6. seam
more is coming soon.
h3. Build/Test Single Component
Be aware that to get this work all dependencies for this component must be installed in maven repo. It can be done by build everything first or by build component and its dependencies using aggregated project as it explained above. You can skip tests for this build and then enable them back when you run single component build.
To build single component use pom.xml in component's folder like it is shown below.
$mvn clean install -f ${component.name}/pom.xml
where ${component.name} is component's root folder name. For instance to build jmx component use command below
$mvn clean install -f jmx/pom.xml
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15513]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 3 months
Re: [jboss-dev-forums] [JBoss ESB Development] - Perhaps SOAPProxy deployment conditions could be relaxed
by Dave Siracusa
Dave Siracusa [http://community.jboss.org/people/davesiracusa] replied to the discussion
"Perhaps SOAPProxy deployment conditions could be relaxed"
To view the discussion, visit: http://community.jboss.org/message/549758#549758
--------------------------------------------------------------
Agreed however making the whole ESB deployment fail because of one errant Web Service seems severe.
It would be great if you had a property to allow me to fail, ignore, retry, use cache, construct on first request, etc.
Right now the code constructs temporary files to cache the WSDL, XSDs, failing back on the temp files would be acceptible under certain conditions.
Of course they would have to be named by category+service-name in order to resolve.
It would also be great if the ?wsdl request entered the pipeline first, this would have made it easier for me to do fixups on modular wsdls.
I will read the thread. Thanks.
BTW - I'm pushing some of these issues via redhat.com support too, sorry about the overlap.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549758#549758]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months