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

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

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | I suppose I could validate the capabilities that say they "ExportPackages" | by running the ExportALL processing even if you explicitly list the package capabilities, | but I'm not sure it really buys much? | You'll still get a ClassNotFoundException on javax.jms.Queue | if you export the package, include it in your filesystem but don't have that class. ;-) Right, but what we want to be able to debug is the question about why javax.jms.Queue is not found when it sitting in my-jms.jar of classloader x. Its going to be common to have classes from the server domain hidden from the application deployment class loader, so why the hidden class is not seen in the question. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131481#4131481 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131481

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: JMS Topics/Queues in ProfileService

by bytor99999

Ah, I didn't see prefill. But would DefaultDS not have its pool created at startup because it is used for messaging or something else? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131480#4131480 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131480

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: JMS Topics/Queues in ProfileService

by bytor99999

"adrian(a)jboss.org" wrote : "scott.stark(a)jboss.org" wrote : Its going to depend on the underlying runtime component providing the stats. The ds don't have them because the pools are not created until needed. | | | | If it's just an issue of lazy pool construction then add something like the following | to your test -ds.xml | | | <min-pool-size>2</min-pool-size> | | <prefill/> | | I was using the DefaultDS which already has <min-pool-size>5</min-pool-size> View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131479#4131479 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131479

18 years, 1 month

1
0
0 / 0

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

by scott.stark＠jboss.org

Ok, thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131471#4131471 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131471

18 years, 1 month

1
0
0 / 0

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

by adrian＠jboss.org

I would update the test to this: | public Map<String, String> compositeSignature; | | public void testMapComposite() throws Exception | { | Field field = getClass().getField("compositeSignature"); | Type mapSignature = field.getGenericType(); | CompositeMetaType result = assertInstanceOf(resolve(mapSignature), CompositeMetaType.class); | MutableCompositeMetaType expected = new MutableCompositeMetaType(HashMap.class.getName(), "HashMap<String,String>"); | expected.addItem("key1", "key1", SimpleMetaType.STRING); | expected.addItem("key2", "key2", SimpleMetaType.STRING); | expected.addItem("key3", "key3", SimpleMetaType.STRING); | expected.freeze(); | | testComposite(expected, result); | | String[] itemNames = {"key1", "key2", "key3"}; | MetaValue[] itemValues = {SimpleValueSupport.wrap("value1"), SimpleValueSupport.wrap("value3"), SimpleValueSupport.wrap("value3")}; | CompositeValueSupport mapValue = new CompositeValueSupport(expected, itemNames, itemValues); | assertEquals("value1", mapValue.get("key1")); | } | Your test will never work, since: | new HashMap<String,String>().getClass() | will just return the erased type, not the generic type. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131470#4131470 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131470

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 : "adrian(a)jboss.org" wrote : | | I'll do them as elements so you can properly customize it. | | With xml wildcards, etc. to define your own. | | | Ok, but then if the attribute form still exists, won't it just be an alias for the most common element construct? To get back to the original question, it seems both included/excluded attributes and include/capability elements make sense. The attributes being shorthand for common element forms. | | In the case where attributes/elements overlap, we have to consider understanding the filter type, | Well actually I coded it as running both filters if you specify both, using a CombiningClassFilter. i.e. it will apply both the package list and any custom filter you specify. ClassLoadingMetaData | | /** | * Get a filter for the included packages | * | * @return the included packages | */ | public ClassFilter getIncluded() | { | ClassFilter packageFilter = null; | if (includedPackages != null) | packageFilter = PackageClassFilter.createPackageClassFilterFromString(includedPackages); | | if (packageFilter == null) | return included; | if (included == null) | return packageFilter; | return CombiningClassFilter.create(true, packageFilter, included); | } | anonymous wrote : | even if only in the management interface to help diagnose conflicts like declaring a p1 capability when p1 was not made visible to the class loader itself. For that we would need access to the raw packages, local packages, and exported packages. | If you declare that you export a package and it doesn't exist, then that's your fault. ;-) But this only comes up with the explicit package capabilties. The filters are not absolute declarations, they are, well, filters on what it finds when scanning the "file system". I suppose I could validate the capabilities that say they "ExportPackages" by running the ExportALL processing even if you explicitly list the package capabilities, but I'm not sure it really buys much? You'll still get a ClassNotFoundException on javax.jms.Queue if you export the package, include it in your filesystem but don't have that class. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131464#4131464 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131464

18 years, 1 month

1
0
0 / 0

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

by scott.stark＠jboss.org

It already exists: http://jira.jboss.com/jira/browse/JBMICROCONT-238 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131460#4131460 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131460

18 years, 1 month

1
0
0 / 0

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

by scott.stark＠jboss.org

Rerunning mvn test from within metatype I only see the CompositeMetaTypeFactoryUnitTestCase failure. This is expected as the MetaTypeFactory impl has not been updated to support MapCompositeMetaType. I'll create the jira for that. | Running org.jboss.test.metatype.types.factory.test.CompositeMetaTypeFactoryUnitTestCase | Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.015 sec <<< FAILURE! | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131459#4131459 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131459

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 : | I'll do them as elements so you can properly customize it. | With xml wildcards, etc. to define your own. | Ok, but then if the attribute form still exists, won't it just be an alias for the most common element construct? To get back to the original question, it seems both included/excluded attributes and include/capability elements make sense. The attributes being shorthand for common element forms. In the case where attributes/elements overlap, we have to consider understanding the filter type, even if only in the management interface to help diagnose conflicts like declaring a p1 capability when p1 was not made visible to the class loader itself. For that we would need access to the raw packages, local packages, and exported packages. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131450#4131450 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131450

18 years, 1 month

1
0
0 / 0

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

by adrian＠jboss.org

I just tried a clean checkout and blew away my local maven repository as well. I get the same result, so it must be something at your end? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131449#4131449 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131449

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