October 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Generic properties on interface and impl class

by alesj

This code already returns 4 methods: | Method[] methods = BeanInfoGenericInterfaceImpl.class.getDeclaredMethods(); | | methods = [ | public void org.jboss.test.beaninfo.support.BeanInfoGenericInterfaceImpl.setProperty(java.lang.String), | | public volatile void org.jboss.test.beaninfo.support.BeanInfoGenericInterfaceImpl.setProperty(java.lang.Object), | | public volatile java.lang.Object org.jboss.test.beaninfo.support.BeanInfoGenericInterfaceImpl.getProperty(), | | public java.lang.String org.jboss.test.beaninfo.support.BeanInfoGenericInterfaceImpl.getProperty()] | Is method being volatile enough to not include it in our declared methods? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4099912#4099912 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4099912

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Deadlock in JBoss Messaging during JBoss5 shutdown

by clebert.suconic＠jboss.com

anonymous wrote : >>The problem is that your code does account for the case where FailoverCommandCenter == null (non clustered), but it's not a MessagingShutdownException on this case, the handleClose will aways be closed... let me explain: The basic problem is, When JBAS is shutdown, case the handleClosing is not complete, the ConnectionConsumer will be waiting forever. So, during a shutdown we need to ensure ConnectionConsumer will finish handleClosing performs a client2server communication before calling clientConsumer.close(): public Object handleClosing(Invocation invocation) throws Throwable | { | | ...... | Long l = (Long) invocation.invokeNext(); <<<< --- this line will fail iif the server was killed... | .... | consumerState.getClientConsumer().close(lastDeliveryId); <<< -- if the server was killed, nothing will close the clientConsumer | | .... | When you have failover in place, the above code is not a problem, as failover will take care of the exception reconnecting everything. But when you don't have a failover logic in place, nothing will close the consumer, what will cause a hang. That's why I aways close the consumer when you don't have a FailoverCommandCenter. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4099898#4099898 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4099898

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Deadlock in JBoss Messaging during JBoss5 shutdown

by timfox

The problem is that your code does account for the case where FailoverCommandCenter == null (non clustered), but it's not a MessagingShutdownException View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4099892#4099892 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4099892

16 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: JBCACHE-1153 - structural nodes

by manik.surtani＠jboss.com

Shall we go with this then? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4099889#4099889 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4099889

16 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Demand / Supply string transformation

by alesj

Done - already commited in the trunk. This test case shows what you can do: | public void testMatching() throws Throwable | { | setBeanMetaDatas(); | | ControllerContext regexpDemand = assertInstall(0, "regexpDemander", getState()); | assertInstall(1, "regexpSupplier"); | assertEquals(ControllerState.INSTALLED, regexpDemand.getState()); | | ControllerContext limitDemand = assertInstall(2, "intervalDemander", getState()); | assertInstall(3, "intervalSupplier"); | assertEquals(ControllerState.INSTALLED, limitDemand.getState()); | | ControllerContext customDemand = assertInstall(4, "customDemander", getState()); | assertInstall(5, "customSupplier"); | assertEquals(ControllerState.INSTALLED, customDemand.getState()); | } | | protected ControllerState getState() | { | return ControllerState.PRE_INSTALL; | } | | protected void setBeanMetaDatas() throws Throwable | { | BeanMetaDataBuilder b0 = BeanMetaDataBuilderFactory.createBuilder("regexpDemander", Object.class.getName()); | b0.addDemand("^[a-zA-Z0-9._%+-]+(a)acme\\.((org)|(com))$", null, "regexp"); | BeanMetaDataBuilder b1 = BeanMetaDataBuilderFactory.createBuilder("regexpSupplier", Object.class.getName()); | b1.addSupply("aj(a)acme.org"); | | BeanMetaDataBuilder b2 = BeanMetaDataBuilderFactory.createBuilder("intervalDemander", Object.class.getName()); | b2.addDemand("(1,10]", null, "interval"); | BeanMetaDataBuilder b3 = BeanMetaDataBuilderFactory.createBuilder("intervalSupplier", Object.class.getName()); | b3.addSupply("5", "java.lang.Integer"); | | BeanMetaDataBuilder b4 = BeanMetaDataBuilderFactory.createBuilder("customDemander", Object.class.getName()); | b4.addDemand("fragment", null, CustomMatcherTransfomer.class.getName()); | BeanMetaDataBuilder b5 = BeanMetaDataBuilderFactory.createBuilder("customSupplier", Object.class.getName()); | b5.addSupply("i supply fragment word"); | | setBeanMetaDatas(new BeanMetaData[] | { | b0.getBeanMetaData(), | b1.getBeanMetaData(), | b2.getBeanMetaData(), | b3.getBeanMetaData(), | b4.getBeanMetaData(), | b5.getBeanMetaData(), | } | ); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4099884#4099884 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4099884

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Deadlock in JBoss Messaging during JBoss5 shutdown

by clebert.suconic＠jboss.com

The problem with that is.. - if you have a remote Server... - if you don't have a cluster connection factory (i.e. no failover) The server will hang on a shutdown, case the remote server was shut before the client. Because that I was checking for FailoverControlCenter on the Exception handler: | ConnectionState connectionState = (ConnectionState)(consumerState.getParent().getParent()); | // if ServerPeer is shutdown or | // if there is no failover in place... we just close the consumerState as well | if (proxiedException instanceof MessagingShutdownException || | (connectionState.getFailoverCommandCenter() == null)) | { | if (!consumerState.getClientConsumer().isClosed()) | { | consumerState.getClientConsumer().close(-1); | } | } | throw proxiedException; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4099883#4099883 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4099883

16 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Parsing behavior FYI

by scott.stark＠jboss.org

I ran into a whitespace issue with an ear that has whitespace surrounding the module path: | <application xmlns="http://java.sun.com/xml/ns/javaee" | xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | version="5" | xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd"> | <description>Application Archive</description> | <display-name>transport_vehicles</display-name> | | | <module> | <java> | transport_ejb_vehicle_client.jar | </java> | </module> | ... | This failed to parse with: | 21:40:05,543 WARN [EARStructure] Error during determineStructure: transport_vehicles.ear | java.lang.RuntimeException: Error determining structure: transport_vehicles.ear at org.jboss.deployment.EARStructure.determineStructure(EARStructure.java:253) | ... | Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Invalid token value: | transport_ejb_vehicle_client.jar | | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:213) | at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:153) | at org.jboss.deployment.EARStructure.determineStructure(EARStructure.java:151) | ... 58 more | Caused by: org.jboss.xb.binding.JBossXBValueFormatException: Invalid token value: | transport_ejb_vehicle_client.jar | | at org.jboss.xb.binding.SimpleTypeBindings.unmarshal(SimpleTypeBindings.java:860) | at org.jboss.xb.binding.sunday.unmarshalling.CharactersHandler.unmarshal(CharactersHandler.java:114) | at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtCharactersHandler.unmarshal(RtCharactersHandler.java:64) | at org.jboss.xb.binding.sunday.unmarshalling.CharactersHandler.unmarshal(CharactersHandler.java:124) | at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtCharactersHandler.unmarshal(RtCharactersHandler.java:64) | at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:1047) | at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:266) | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.endElement(SaxJBossXBParser.java:384) | at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) | at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source) | at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) | at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) | at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) | at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) | at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) | at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) | at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) | at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:209) | ... 60 more | Turned out the metadata-beans.xml binding for application_5.xsd schema location was incorrectly using application_5_0.xsd. Because of this the schema was being generated from the schema by the XsdBinder and somehow this was changing the behavior of the characters callback. I'm not clear where this change was happening as the ContentHandler.characters(char[] ch, int start, int length) callback value was different in the two cases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4099881#4099881 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4099881

16 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generic properties on interface and impl class

by alex.loubyansky＠jboss.com

It seems like this issue actually affects a number of tests in xb project, not just the recently discovered. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4099863#4099863 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4099863

16 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Generic properties on interface and impl class

by alex.loubyansky＠jboss.com

This issue was initially discussed in XB forums http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4099492#4099492 The testcase is very simple and is in the mc testsuite package org.jboss.test.beaninfo.test; public class BeanInfoUnitTestCase extends AbstractBeanInfoTest public void testGenericInterfaceImpl() throws Throwable During the metadata discussion we decided it was a bug in the BeanInfo API. I haven't created a Jira issue for this yet though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4099857#4099857 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4099857

16 years, 6 months

1
0
0 / 0

[Design of JBoss Transaction Services] - tx propagation over JRMP

by jhalliday

Can anyone familiar with the JRMP invokers suggest how best to make them handle transaction contexts in a more flexible fashion. The use case I'm interested in is where true distributed transactions are needed, rather than just client side control of transactions boundaries for tx that reside in the server. Using the JBossTS JTS is possible where the transport is RMI/IIOP, since it has interceptors to handle the transaction propagation. That does not work with client side JRMP proxies for e.g. EJBs, since they are not aware of the JTS tx context on the client thread. What is the best solution here? Ideally there should be some pluggable way of having the JRMP transport find the tx context on the client thread, serialize it and deserialize it on the server side. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4099853#4099853 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4099853

16 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2007