November 2009 - jboss-dev-forums - Jboss List Archives

[JBoss Microcontainer Development] - Re: Non-public field properties

by alesj

We don't do too much magic - which is what 330 supports. e.g. | public class Foo | { | @Inject | public Foo(SomeMappedBean smb) | ... | } | We require a bit more explicit wiring | public class Foo | { | @Constructor | public Foo(@Inject SomeMappedBean smb) | ... | } | Which is already handled by @Constructor ctor plugin. Plus the properties plugin should also be an Annotation2ValueMetaDataAdapters instance. But I guess once we introduce qualifiers for MC in general, we should support the example above - @Inject on ctor. Which means your plugin is OK, but it could use a bit nicer code. ;-) e.g. there already exist a code that checks for AbstractBeanMetaData instance of View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266043#4266043 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266043

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Non-public field properties

by kabir.khan＠jboss.com

Although my tests for @Inject work fine now, I am not 100% sure I am using the right annotation plugins. Here's what I am doing for @Inject annotated constructors: | public class Jsr330InjectConstructorAnnotationPlugin extends ConstructorAnnotationPlugin<Inject> | { | public static final Jsr330InjectConstructorAnnotationPlugin INSTANCE = new Jsr330InjectConstructorAnnotationPlugin(); | | protected Jsr330InjectConstructorAnnotationPlugin() | { | super(Inject.class); | } | | protected List<? extends MetaDataVisitorNode> internalApplyAnnotation(ConstructorInfo info, Inject annotation, BeanMetaData beanMetaData) throws Throwable | { | if (info.getParameters().length == 0) | return null; | if (beanMetaData instanceof AbstractBeanMetaData == false) | throw new IllegalArgumentException("beanMetaData is not a AbstractBeanMetaData"); | | AbstractConstructorMetaData constructor = new AbstractConstructorMetaData(); | | List<ParameterMetaData> values = new ArrayList<ParameterMetaData>(info.getParameters().length); | for (ParameterInfo parameter : info.getParameters()) | values.add(new AbstractParameterMetaData(Jsr330InjectionResolver.createValueMetaData(parameter.getParameterType().getType(), parameter.getUnderlyingAnnotations()))); | | constructor.setParameters(values); | ((AbstractBeanMetaData)beanMetaData).setConstructor(constructor); | | return Collections.singletonList(constructor); | } | | @Override | protected void internalCleanAnnotation(ConstructorInfo info, MetaData retrieval, Inject annotation, | KernelControllerContext context) throws Throwable | { | if (context.getBeanMetaData() instanceof AbstractBeanMetaData == false) | throw new IllegalArgumentException("beanMetaData is not a AbstractBeanMetaData"); | ((AbstractBeanMetaData)context.getBeanMetaData()).setConstructor(null); | } | } | I see elsewhere that the ConstructorParameterAnnotationPlugin is used, which takes a set of Annotation2ValueMetaDataAdapters used to parse the parameters. However, Annotation2ValueMetaDataAdapters need to know which annotation is being used, which in the case of Annotation2ValueMetaDataAdapters is unknown, since the trigger is looking for @Qualifier on the parameter annotations. Also, parameters might not have any annotations which is probably currently handled some other way for normal injection. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266033#4266033 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266033

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by thomas.diesler＠jboss.com

Hi Ales, when working on this, please also keep in mind that the standard wiring and injection mechanism in OSGi is Blueprint. If there is some sort of integration between MC and BP beans and services it should show up in the BP descriptor. The BP descriptor has a namespace extension build into it which could be used to declare or reference MC beans. If you also think of bringing the notion of OSGi service to the MC descriptor then that would be of secondary importance. Anyhow, could you please describe how the MC/OSGiService integration would work from the user perspective. Not sure if you are aware of this, but we already have some sort of MC/OSGiService integration which is detailed in the MicrocontainerService http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapProvidedBundles.htm... and tested in by the http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapProvidedExamples.ht... Could you please add a comment to https://jira.jboss.org/jira/browse/JBOSGI-141 that details what added benefits your current integration work will bring to the user? Thanks a bunch View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266027#4266027 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266027

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Non-public field properties

by kabir.khan＠jboss.com

Thanks it works for private fields with ALL, and I'll get rid of the tests for private methods, setters and constructors. "alesj" wrote : | Wrt JSR330 I wouldn't follow all their rules, | I would mostly use its annotations to unify the usage, | hence increase portability. | Do you think I should implement @Scope and @Singleton? | public class SimpleFieldBean | { | @Inject | public Simple field; | | @Inject | public Simple other; | } | The way this is described is that in my original SimpleFieldBean example, if Simple has no annotations a new instance is injected for each use, i.e. field != other. If Simple has a @Scope annotated annotation, such as @Singleton, the same instance is injected, so field == other, which in effect is what we have now. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266025#4266025 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266025

16 years, 4 months

1
0
0 / 0

[JBoss AS Development Deployment Framework] - Re: ear not deployed in JBoss start up with derby database

by akhilachuthan

I have derby.jar and derbyclient.jar placed in my lib folder.... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266007#4266007 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266007

16 years, 4 months

1
0
0 / 0

[JBoss AS Development Deployment Framework] - ear not deployed in JBoss start up with derby database

by akhilachuthan

hello I am trying to start my jboss(5.1) with derby, but my ear does not get deployed at all... Jboss gives an impression that it has started, when i look in inside my ear is not noticed by jboss at all...... The same setup works fine with oracle and mysql, with my ear properly deployed.... Any help??? the below is the contents of my datastore xml: <local-tx-datasource> <jndi-name>DefaultDS</jndi-name> <connection-url>jdbc:derby:MY_DATABASE;create=true</connection-url> <driver-class>org.apache.derby.jdbc.EmbeddedDriver</driver-class> <user-name>NA</user-name> NA  <track-statements>true</track-statements> <max-pool-size>40</max-pool-size> <blocking-timeout-millis>30000</blocking-timeout-millis> <exception-sorter-class-name>com.dhyan.nms.server.genlib.database.dberror.DataBaseErrorChecker</exception-sorter-class-name>    <type-mapping>Derby</type-mapping> </local-tx-datasource> View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266006#4266006 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266006

16 years, 4 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: Getting rid of conf/jboss-service.xml

by scott.stark＠jboss.org

I have the naming service, and in fact all services moved out of the conf/jboss-service.xml, but I see DML is working on this as issue JBAS-6948. Once I clarify what his status is I can figure out how to commit the changes to trunk. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265987#4265987 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265987

16 years, 4 months

1
0
0 / 0

[jBPM Development] - Re: SQL Exception throws in JBPM 3.1.4 while changing the Hi

by darshgohel

Thanks for the quick response. I will take care of this. Regards, Darshan. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265986#4265986 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265986

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - How does bundle resolution work

by thomas.diesler＠jboss.com

Here is a short explanation of how bundle resolution (currently) works. The OSGiBundleClassLoadingDeployer creates the package capabilities/requirements that map to package exports/imports respectively. At runtime the MC iterates over all modules, all requirements, all capabilities. For every OSGiPackageCapability it callls | boolean OSGiPackageCapability.resolves(Module reqModule, Requirement requirement) | The initial implementation, that did not use an external resolver would compare the package name and various other constraints. If a match was determined, this method would return true and irrevocably associate the capability with the requirement. Effectively establishing the wire from the package exported to the importer. There are various problems with this approach. Conceptually, bundles cannot be resolved by simply looking at a single package import/export combination. If multiple exporters are available the first one this approach would find is not necessarily the one that can be used for the overall bundle resolution. Consider this | BundleC | exports A, B | imports A | | BundleD | exports A, | imports A, B, C | To resolve BundleC the resolver would have two choices. It could either use the self-import from of package A or import package A from BundleD. If it chooses the latter, both bundles cannot resolve because of the missing import of package C. Generally, because the resolve algorithm that is currently available in the MC is not yet suitable for the rich OSGi semantics we (i.e. Ales and I ) agreed to work on a pluggable module resolver. A correct resolver can reason about all possible wirings and may need to retry different wirings to find the best resolution. This becomes especially important when we add support for the uses clause on export packages. The related issues are https://jira.jboss.org/jira/browse/JBKERNEL-54 https://jira.jboss.org/jira/browse/JBKERNEL-55 In JBoss OSGi this is captured by https://jira.jboss.org/jira/browse/JBOSGI-151 The current workaround is that there is the notion of a resolver in the OSGi layer that somehow predetermines the wiring, which is triggered from PackageAdmin.resolveBundles | PackageAdmin.resolveBundles(Bundle[] bundleArr) | | // Resolve the bundles through the resolver | Resolver bundleResolver = bundleManager.getPlugin(ResolverPlugin.class); | List<OSGiBundleState> resolvableBundles = new ArrayList<OSGiBundleState>(); | for (Resolvable aux : bundleResolver.resolve(unresolvedBundles)) | resolvableBundles.add(OSGiBundleState.assertBundleState(aux.getBundle())); | The OSGiPackageCapability simply picks up the result from the Resolver and does not attempt do compute the resolution itself. | boolean OSGiPackageCapability.resolves(Module reqModule, Requirement requirement) | | // Get the exporter for this requirement | ExportPackage exporter = bundleResolver.getExporter(reqBundle, packageRequirement.getName()); | if (exporter == null) | return false; | The call into OSGiPackageCapability.resolves returns false for every combination but the one the Resolver has previously determined. This is of course still very inefficient and not the right place to do it apart from that the current BasicResolverImpl is (as the name suggests) indeed very basic (i.e. wrong). However it allows us to run the OSGi enterprise examples against the MC Framework on all supported target containers, which was the release criteria for Beta4. In future that or a similar resolver API would bubble up into the MC layer and become a native part of its module resolution algorithm. For the time being the notion of external resolver however needs to stay in order to make good progress on the OSGi core TCK. This has currently highest priority and will result in functionality that allows folks to be able to actually deploy standard OSGi bundles and see them work as they should on all supported target containers. An alternative approach would be, to disable the Resolver and somehow still pass all the enterprise osgi examples and functional tests that are there already. This was our first approach, but unfortunately proved infeasible - so the alternative of external resolution came about. merci View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265982#4265982 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265982

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: JBoss OSGi logging policy

by thomas.diesler＠jboss.com

anonymous wrote : | I can't run tests from inside eclipse without modifying it and I'm going to | forget to revert it from time to time on commits. | In every projects pom there is a comment that tells you what properties to set in the eclipse test configurations to achieve the same runtime behaviour as from the command line. For the Framework that would be | -Dlog4j.output.dir=${workspace_loc:jboss-osgi-framework/target} | -Dorg.jboss.osgi.framework.launch.bootstrapPath=bootstrap/jboss-osgi-bootstrap.xml | This is needed because the system properties that are defined on the surefire plugin are unfortunately not used by the eclipse test runs, which is a general problem that applies to all system properties that should be available at test runtime. I've seen test cases that duplicate the settings from the pom and hard code them into the test. This IMHO is not so good. Instead system properties should go into the eclipse test configuration. I also run tests from eclipse on a daily basis, once the props are set in eclipse its should be all good. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265977#4265977 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265977

16 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2009