February 2008 - jboss-dev-forums - Jboss List Archives

[Deployers on JBoss (Deployers/JBoss)] - Re: Deploying multiple service through the ServiceDeployer

by thomas.diesler＠jboss.com

Please don't rollback just yet. I modify based on your feedback. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131420#4131420 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131420

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: SpecialValueFactoryUnitTestCase failure

by adrian＠jboss.org

I'm not seeing either of these. A clean build (not a clean checkout) comes up with this error, which is from Scott's latest commit... | Results : | | Tests in error: | testMapComposite(org.jboss.test.metatype.types.factory.test.CompositeMetaTypeFactoryUnitTestCase) | | Tests run: 154, Failures: 0, Errors: 1, Skipped: 0 | | ------------------------------------------------------------------------------- | Test set: org.jboss.test.metatype.types.factory.test.CompositeMetaTypeFactoryUnitTestCase | ------------------------------------------------------------------------------- | Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.125 sec <<< FAILURE! | testMapComposite(org.jboss.test.metatype.types.factory.test.CompositeMetaTypeFactoryUnitTestCase) Time elapsed: 0.022 sec <<< ERROR! | java.lang.ClassCastException: org.jboss.metatype.api.types.ImmutableTableMetaType | at org.jboss.test.metatype.types.factory.test.CompositeMetaTypeFactoryUnitTestCase.testMapComposite(CompositeMetaTypeFactoryUnitTestCase.java:140) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131419#4131419 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131419

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: ServiceMetaData has the most recent dependencies/attribu

by anil.saldhana＠jboss.com

I have | public class EarJaccPolicy extends JaccPolicy<JBossAppMetaData> | { | public EarJaccPolicy(String id) | { | super(id); | } | | | public EarJaccPolicy(String id, JBossAppMetaData metaData, Boolean standaloneDeployment) | { | super(id, metaData, standaloneDeployment); | } | } | When there is an ear with ejb3 deployment, the ServiceCreator (internally the MBeanServer) is choking with: | Caused by: java.lang.NoSuchMethodException: org.jboss.deployment.security.EarJaccPolicy.<init>(java.lang.String, org.jboss.metadata.ear.jboss.JBoss50AppMetaData, java.lan | g.Boolean) | at java.lang.Class.getConstructor0(Class.java:2647) | at java.lang.Class.getConstructor(Class.java:1629) | at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:1241) | at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:286) | at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:344) | at org.jboss.system.ServiceCreator.installPlainMBean(ServiceCreator.java:197) | at org.jboss.system.ServiceCreator.install(ServiceCreator.java:115) | ... 84 more | The ServiceConstructorMetaData is as follows: | ServiceConstructorMetaData serviceConstructor = new ServiceConstructorMetaData(); | serviceConstructor.setSignature(new String[] { String.class.getName(), | metaData.getClass().getName(),Boolean.class.getName()}); | serviceConstructor.setParameters(new Object[] {contextId,deployment, Boolean.TRUE}); | createJaccPolicyBean(serviceConstructor, unit); | | where metadata is JBossAppMetaData instance. (I Think this is where I need to ensure that JBossAppMetaData is passed) | A fix is to add a ctr with JBoss50AppMetaData to EarJaccPolicy. But it seems too much to add ctrs with JBoss60AppMetaData, JBoss70AppMetaData..... It probably is simple reflection semantics. I think the fix is in the ServiceConstructorMetaData...... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131418#4131418 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131418

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassLoadingMetaData ease-of-use

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | Can we use the osgi/mathematical syntax of a version range to specify from/to behaviors? | | | <... version="[1.2.3, 4.5.6)" /> | | | meaning the version must be in the range, 1.2.3 <= version < 4.5.6 | I can add it as an option.It is probably more prone to error and easily forgotten by non-mathematicians though? :-) And as you'll see in this example, it's not really any terser. | <requirements> |  | <module name="test" range="[1.2.3, 4.5.6)"/> | <!-- is the same as -> | <module name="test" from="1.2.3" to="4.5.6"/> | NOTE: The toString() of VersionRange already uses that syntax. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131411#4131411 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131411

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: SpecialValueFactoryUnitTestCase failure

by alesj

I've got this two tests failing for me: - CompositeMetaTypeFactoryUnitTestCase - VFSClassLoaderFactoryUnitTestCase And there could be more (I got the 2nd one by commenting CCE in the first) Like said, 1st is CCE. 2nd one: | Caused by: org.jboss.xb.binding.JBossXBRuntimeException: {urn:jboss:classloader:1.0}classloader not found as a child of {urn:jboss:bean-deployer:2.0}deployment | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131410#4131410 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131410

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - SpecialValueFactoryUnitTestCase failure

by scott.stark＠jboss.org

I just pulled down the current mc trunk contents and did a mvn install, and the SpecialValueFactoryUnitTestCase is failing to start: | Running org.jboss.test.metatype.types.test.MetaTypeUnitTestCase | Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec | Running org.jboss.test.metatype.values.factory.test.SpecialValueFactoryUnitTestCase | [INFO] ------------------------------------------------------------------------ | [ERROR] BUILD FAILURE | [INFO] ------------------------------------------------------------------------ | [INFO] There are test failures. | | Please refer to /home/svn/JBossMC/jbossmc/metatype/target/surefire-reports for the individual test results. | [INFO] ------------------------------------------------------------------------ | [INFO] For more information, run Maven with the -e switch | [INFO] ------------------------------------------------------------------------ | [INFO] Total time: 6 minutes 11 seconds | [INFO] Finished at: Fri Feb 22 06:13:47 PST 2008 | [INFO] Final Memory: 29M/114M | [INFO] ------------------------------------------------------------------------ | [starksm@succubus jbossmc]$ | | [starksm@succubus jbossmc]$ cat metatype/target/surefire-reports/org.jboss.test.metatype.values.factory.test.SpecialValueFactoryUnitTestCase-output.txt | org.apache.maven.surefire.booter.SurefireExecutionException: Unresolved compilation problem: | ; nested exception is java.lang.Error: Unresolved compilation problem: | | java.lang.Error: Unresolved compilation problem: | | at org.jboss.metatype.api.types.MetaTypeFactory.getInstance(MetaTypeFactory.java:46) | at org.jboss.test.metatype.values.factory.test.AbstractMetaValueFactoryTest.<clinit>(AbstractMetaValueFactoryTest.java:43) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:597) | at org.apache.maven.surefire.junit.JUnitTestSet.createInstanceFromSuiteMethod(JUnitTestSet.java:180) | at org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject(JUnitTestSet.java:140) | at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:197) | at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) | at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) | at org.apache.maven.surefire.Surefire.run(Surefire.java:177) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:597) | at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) | at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131409#4131409 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131409

18 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Re: Facade Questions

by adrian＠jboss.org

"johnbailey" wrote : Ok. I will start on the facade assuming there will be at least a DeploymentUnit available. If the Unit has an attached ControllerContext, it will delegate to the attached version, otherwise it will create a DeployentContollerContext. Does this seem like the correct approach? | They will always be available. The only time you need to create them in the OSGi layer is in the BundleContext::installBundle() methods which you will do indirectly by delegating to the main deployer. anonymous wrote : | It seems like the BundleContext will need access to the DeploymentUnit in order to create ServiceReferences, which I see as components of the Deployment. Make sense? | Yes, ServiceReferences are deployment components that are installed as "ServiceReferenceControllerContexts" into the MC. They're really just facades on top of any ControllerContext. This allows us to expose MBeans and POJOs (using the same facade) as OSGi services and also potentially dependency inject OSGi services into mbeans and pojos. Ales can tell you which parts are already done and what the classes are really called, the devil is always in the details. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131407#4131407 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131407

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: ServiceMetaData has the most recent dependencies/attribu

by dimitris＠jboss.org

"alesj" wrote : "anil.saldhana(a)jboss.com" wrote : | | The apostle from Slovania makes a point. ;) | Read my location more precisely and do a copy/paste, since your geography sucks. ;-) "Solvenia" maybe ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131406#4131406 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131406

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ClassLoadingMetaData ease-of-use

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | 1.0.0 <= version <= 1.0.0 | ... | FROM VERSION | ... | TO VERSION | ... | Can we use the osgi/mathematical syntax of a version range to specify from/to behaviors? | <... version="[1.2.3, 4.5.6)" /> | meaning the version must be in the range, 1.2.3 <= version < 4.5.6 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131405#4131405 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131405

18 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Re: Facade Questions

by johnbailey

Ok. I will start on the facade assuming there will be at least a DeploymentUnit available. If the Unit has an attached ControllerContext, it will delegate to the attached version, otherwise it will create a DeployentContollerContext. Does this seem like the correct approach? It seems like the BundleContext will need access to the DeploymentUnit in order to create ServiceReferences, which I see as components of the Deployment. Make sense? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131403#4131403 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131403

18 years, 1 month

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 February 2008