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

[Design of JBossXB] - Re: JBossEntityResolver and xsd:redefine resolution

by alex.loubyansky＠jboss.com

A testcase in the xb that reproduces the issue is jbossxb/trunk/src/test/java/org/jboss/test/xb/schemaresolver/test/DefaultSchemaResolverUnitTestCase.java View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136648#4136648 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136648

18 years

1
0
0 / 0

[Design of JBossXB] - JBossEntityResolver and xsd:redefine resolution

by alex.loubyansky＠jboss.com

The issue was discovered in http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136295#4136295 The problem is that when the schema that contains xsd:redefine is parsed and when the redefine is resolved, the arguments passed to the JBossEntityResolver.resolve(publicId, systemId) are: - publicId is the namespace of the schema that contains xsd:redefine - systemId is the schemaLocation attribute of the xsd:redefine In some cases (i.e. if the namespace of the redefining schema is mapped to its schema location in the JBossEntityResolver and both schemas are in the classpath) this results in StackOverflowError since the JBossEntityResolver is looking at the publicId first during resolveEntity. I want to change this to check if the publicId is registered and if the registered schemaLocation is different from the systemId argument then try resolving the systemId argument first. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136646#4136646 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136646

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Field injection

by alesj

A first hurdle. How to get past this usage in PropertyDispatchWrapper (kernel module): | PropertyInfo propertyInfo = BeanInfoUtil.getPropertyInfo(beanInfo, target, name); | ValueMetaData valueMetaData = property.getValue(); | Object value = valueMetaData.getValue(propertyInfo.getType(), cl); | beanInfo.setProperty(target, name, value); | Since I need the expected type of the value in order to convert it to the right type, e.g. string --> Date. But what if my bean is in FIELD or ALL mode, and there is no such property? Anything that comes to my mind in api extension to get the type by name from BeanInfo feels wrong. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136640#4136640 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136640

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBDEPLOY-3 issues

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | btw: What's the mechanism? | | I'll just put 'Managed* api' for now. | | For now, just leave the type mechanism in the code, but deprecate it | and get scott to update the warning once he has done the work in the profile service | to make it work. We can then remove the code but NOT the method signature | until we know everybody has made the switch. | | | | log.warn("Types should be set using <Scott to provide mechansim/> for " + this); | | | | :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136639#4136639 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136639

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBDEPLOY-3 issues

by alesj

"adrian(a)jboss.org" wrote : That is unless you want to go through all the deployers that exist | to get jboss-head to compile/boot. :-) | Hehe, thought this might come up. That's why I didn't want to remove type on the deployers in the first place. :-) OK, will do that. btw: What's the mechanism? I'll just put 'Managed* api' for now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136627#4136627 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136627

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBDEPLOY-3 issues

by adrian＠jboss.org

"alesj" wrote : | A fair warning: all AS5 deployers that define type should get that removed from xml, since setType is not longer there ;-) | Fair warning is a message to the dev-list with a title that has block capitals and an explanation of what people need to do to get the correct behaviour. In this case, the change to managed object should have gone into jbossas first before we removed this from the deployers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136625#4136625 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136625

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBDEPLOY-3 issues

by adrian＠jboss.org

Can you put setType() back please, but re-implement it like this: | @Deprecated | public void setType(...) | { | log.warn("Types should be set using <mechanism here/> for " + this); | } | That is unless you want to go through all the deployers that exist to get jboss-head to compile/boot. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136622#4136622 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136622

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Generalizing dependency injection

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : So what is the benefit to BeanFactory over an instance factory on the bean ctor metadata? I wouldn't describe it as a benefit, its a different semantic. Factory construction is just an alternate way to construct a singleton | <bean> | <constructor factroyClass="x.y.z.A" factoryMethod="create"/> | A bean factory creates an object that implements BeanFactory on which you can call create() to create as many instances as you like: | <beanfactory name="MyFactory"> | ... | | public class MyClass | { | @Inject("MyFactory") | public void setFactory(BeanFactory factory) {} | | public void doStuff() | { | Object one = factory.create(); | Object two = factory.create(); | } | } | The main usecase of beanfactory so far has been to do dependency injection into aop's advices. http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontaine... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136619#4136619 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136619

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Handling Large Files in JBossESB FileGateway

by tfennelly

Forgot to mention... you configure your new composer impl on the FileGateway via the "composer-class" property. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136601#4136601 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136601

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Handling Large Files in JBossESB FileGateway

by tfennelly

You should be able to do this by writing a custom MessageComposer (org.jboss.soa.esb.listeners.message.MessageComposer). e.g. a "FileInputStreamMessageComposer" that simply opens the file InputStream on the compose() call, attaches the stream as the message payload for processing by the action pipeline, and closes the InputStream on the decompose() call. We'd be happy to receive this back as a contribution :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136599#4136599 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136599

18 years

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