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

[Design the new POJO MicroContainer] - Re: WiredMicrocontainerTest

by alesj

"adrian(a)jboss.org" wrote : | I already went through and fixed this once and combined three or four classes you'd created in the package back into the main test class. :-) | There's a previous thread about it somewhere? | You call it 'N<->M problem', I call it OO approach. :-) OK, I'll fix this one into the MicrocontainerTest. Plus any other future crazy generic idea that I get. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134221#4134221 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134221

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: WiredMicrocontainerTest

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : Either add the feature to the MicrocontainerTest class or move it to src/tests | I don't want all the tests to be autowired. | But on the other hand this is a generic MC test util, so imho it should be where it is. | As a user I don't want to pull all the kernel tests just to get what the kernel module is all about, this test. :-) MicrocontainerTest is the exported test. I don't want lots of different test parents with the N<->M problem for different features. I already went through and fixed this once and combined three or four classes you'd created in the package back into the main test class. :-) There's a previous thread about it somewhere? The correct way to do this, if you want subclasses to use it is to allow it to be enabled with something like: | public MyTest(String name) | { | super(name); | // or whatever you want to call the property | setRegisterTestInController(true); | } | The same goes for any other features you think are generic enough to be used elsewhere. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134209#4134209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134209

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Wildcards and JBossXb Builder

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | The fix is for you to learn xsd, XSD 1.0.1 :-) | | | Looks like not that I'll only learn, I'll have to make a whole degree out of it. | I though JBossXB Builder was here to relieve the xsd pain, but it's turning to be the other way around ... :-) | No. The port to JBossXBBuilder has just caught the fact that you didn't do the original work correctly ;-) It's like what I found when I really tested the javabean constructor stuff from the container project (see other thread with the jira issue :-) "adrian(a)jboss.org" wrote : | i.e. we create an mc-commons.xsd and you xsd:redefine that into your namespace. | You can then use all the mc xsd types in your namespace and the user | doesn't have to write all those xmlns directives. ;-) | And how does this affect jaxb usage? I don't understand the question. Did you even read the thread I had with Kabir? You're a fast reader if you did, it was a long thread. Here's a different summary. The idea is to make the value type and group (and other xsd artificats from the mc) part of your schema/namespace. 1) It will make your life simpler since you can just reuse the already defined parsing e.g. this will automagically create a value element/type in your namespace with the MC's value group defined in your namespace | @XmlElement(name="value") | public void setValue(ValueMetaData value) | and it will be maintained going forwards as it evolves. The same goes for the schema definition via mc-commons.xsd 2) It will make the user's life simpler since they don't have to type xmlns all over the place (or think about which namespace it belongs in) | <policy xmlns="urn:jboss:policy:1.0"> | <binding name="somename"> |  | <value class="java.lang.Integer">42</value> | </binding> | </policy> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134204#4134204 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134204

18 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Re: ServiceReferences outside of OSGi Deployers

by adrian＠jboss.org

"johnbailey" wrote : Ok. I am working on creating a ServiceRegistry. I am following the advice to use a Deployer to trap all component deployments to get ServiceRegistrations/References for no OSGi deployments. | That wasn't advice, that was just a hack to get something working until it is done properly. :-) I don't like the idea of creating an extra registry just to do "indexing" of component -> deployment or feature -> component (where feature is implemented interface or some property of the service) we should add this to our native stuff, i.e. the controller/context. See the discussion I had with Ales about spring-int last year. SUMMARY: He was adding features only available in the spring integration (e.g. default create method at the deployment level) when those should have been available in our native POJOs and spring just reusing them. anonymous wrote : | The current ServiceRegistrationImpl is wrapping a KernelControllerContext. So when the ServiceRegistry receives a component deployment, there isn't a KernelControllerContext available. Should I lookup the KernelControllerContext from the Kernel, to create the ServiceRegistration? | If you're using the hack mentioned above, then you should be able to add your deployer to the INSTALL stage where you can lookup the ControllerContext in the Controller using the Component deployment's name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134200#4134200 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134200

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: WiredMicrocontainerTest

by alesj

"adrian(a)jboss.org" wrote : Either add the feature to the MicrocontainerTest class or move it to src/tests I don't want all the tests to be autowired. But on the other hand this is a generic MC test util, so imho it should be where it is. As a user I don't want to pull all the kernel tests just to get what the kernel module is all about, this test. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134199#4134199 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134199

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Wildcards and JBossXb Builder

by alesj

"adrian(a)jboss.org" wrote : | The fix is for you to learn xsd, XSD 1.0.1 :-) | Looks like not that I'll only learn, I'll have to make a whole degree out of it. I though JBossXB Builder was here to relieve the xsd pain, but it's turning to be the other way around ... :-) "adrian(a)jboss.org" wrote : | i.e. we create an mc-commons.xsd and you xsd:redefine that into your namespace. | You can then use all the mc xsd types in your namespace and the user | doesn't have to write all those xmlns directives. ;-) | And how does this affect jaxb usage? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134196#4134196 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134196

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - WiredMicrocontainerTest

by adrian＠jboss.org

This should not be in src/main. Either add the feature to the MicrocontainerTest class or move it to src/tests View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134195#4134195 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134195

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Wildcards and JBossXb Builder

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | I(t) shouldn't be working though. Its probably only working because | you've hacked it in the schema initializer. :-) | | Problems: | 1) the MC schema doesn't export a "value" element | 2) the policy schema doesn't even define an xsd:any element :-) | This is really a more generic problem. The best way to catch this in the long term (e.g. making sure people define the schema properly when they change the metadata/parsing) is to enable validation of the xml against the schema in our xml parsing tests (and optionally on the BaseXmlDeployer/MicrocontainerTest). See the SchemaResolverDeployer for how to do this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134194#4134194 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134194

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Wildcards and JBossXb Builder

by adrian＠jboss.org

"alesj" wrote : "alex.loubyansky(a)jboss.com" wrote : So far, it's an XML/XSD issue (except for that lax=false issue). If you think the XML is valid then the schema has to be fixed by making value a root element. | This is already working if I use the old approach - with SchemaInitializer. | But I fail to get it working with JBossXB Builder. | See BindingTestCase vs. BindingJaxbTestCase. I shouldn't be working though. Its probably only working because you've hacked it in the schema initializer. :-) Problems: 1) the MC schema doesn't export a "value" element 2) the policy schema doesn't even define an xsd:any element :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134190#4134190 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134190

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Wildcards and JBossXb Builder

by adrian＠jboss.org

What I'd propose is what I discussed with Kabir here: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132601#4132601 See point (3). i.e. we create an mc-commons.xsd and you xsd:redefine that into your namespace. You can then use all the mc xsd types in your namespace and the user doesn't have to write all those xmlns directives. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134186#4134186 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134186

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