[Design of AOP on JBoss (Aspects/JBoss)] - Re: Implementing JAXB style parsing for aop-mc-int
by kabir.khan＠jboss.com
To complete my previous stack trace, if I turn on the redefine part, the entry point into the infinite recursion is
| ...
| XSDHandler.constructTrees(Element, String, XSDDescription) line: not available
| XSDHandler.constructTrees(Element, String, XSDDescription) line: not available
| XSDHandler.parseSchema(XMLInputSource, XSDDescription, Hashtable) line: not available
| XMLSchemaLoader.loadSchema(XSDDescription, XMLInputSource, Hashtable) line: not available
| XMLSchemaLoader.loadGrammar(XMLInputSource) line: not available
| XSLoaderImpl.load(LSInput) line: not available
| Util.loadSchema(InputStream, String, SchemaBindingResolver) line: 395
| XsdBinder.bind(InputStream, String, SchemaBindingResolver, boolean) line: 175
| XsdBinder.bind(InputStream, String, String, boolean) line: 146
| DefaultSchemaResolver.resolve(String, String, String) line: 330
| WildcardBinding.getElement(QName, Attributes) line: 174
| SequenceBinding$1.startElement(QName, Attributes, Set, List, boolean) line: 307
| SequenceBinding$1.startElement(QName, Attributes, Set, List, boolean) line: 254
| SequenceBinding$1(ModelGroupBinding$Cursor).startElement(QName, Attributes) line: 185
| SundayContentHandler.startElement(String, String, String, Attributes, XSTypeDefinition) line: 447
| SaxJBossXBParser$DelegatingContentHandler.startElement(String, String, String, Attributes) line: 407
| SAXParserImpl$JAXPSAXParser(AbstractSAXParser).startElement(QName, XMLAttributes, Augmentations) line: not available
| XIncludeHandler.startElement(QName, XMLAttributes, Augmentations) line: not available
| XMLNSDocumentScannerImpl.scanStartElement() line: not available
| XMLNSDocumentScannerImpl$NSContentDispatcher(XMLDocumentFragmentScannerImpl$FragmentContentDispatcher).dispatch(boolean) line: not available
| XMLNSDocumentScannerImpl(XMLDocumentFragmentScannerImpl).scanDocument(boolean) line: not available
| XIncludeAwareParserConfiguration(XML11Configuration).parse(boolean) line: not available
| XIncludeAwareParserConfiguration(XML11Configuration).parse(XMLInputSource) line: not available
| SAXParserImpl$JAXPSAXParser(XMLParser).parse(XMLInputSource) line: not available
| SAXParserImpl$JAXPSAXParser(AbstractSAXParser).parse(String) line: not available
| SAXParserImpl$JAXPSAXParser.parse(String) line: not available
| SaxJBossXBParser.parse(String, JBossXBParser$ContentHandler) line: 173
| UnmarshallerImpl.unmarshal(String, SchemaBindingResolver) line: 139
| BasicXMLDeployer.deploy(URL) line: 147
| AOPMicrocontainerTestDelegate(MicrocontainerTestDelegate).deploy(URL) line: 297
| AOPMicrocontainerTestDelegate(MicrocontainerTestDelegate).deploy() line: 441
| AOPMicrocontainerTestDelegate.deploy() line: 76
| AOPMicrocontainerTestDelegate(MicrocontainerTestDelegate).setUp() line: 86
| AOPMicrocontainerTestDelegate.setUp() line: 60
|
Also, my jboss-beans-common_2_0.xsd header looks like
| <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
| targetNamespace="urn:jboss:beans-common:2.0"
| xmlns="urn:jboss:beans-common:2.0"
| elementFormDefault="qualified"
| attributeFormDefault="unqualified"
| version="1.0">
| ...
|
I will try removing the namespace from that, and see if that breaks it
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135718#4135718
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135718
18 years
[Design of JBossCache] - Re: New state transfer in JBoss Cache
by manik.surtani＠jboss.com
"Bela Ban" wrote :
| What happens with asynchronous replication ? A committed TX will be sent asynchronously in a one-phase commit as a combined PREPARE/COMMIT to D. Does D queue these ?
|
| ANSWER: we don't need to queue them because they will get applied to A's state, and so we have them as part of A's state...
|
No, but just like 2PC messages, D needs to respond positively to 1PC prepare/commit messages so that the tx originator can complete the txs. After responding positively, D would discard the messages assuming that they will either be incorporated in A's state or be a part of the tx log A sends along with the state.
"Bela Ban" wrote :
| Idempotency: creation, deletion and moving of data/nodes is not imdempotent. Is idempotency required in this design ?
|
Need to think whether idempotency is still a requirement even after changes made in Orlando.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135714#4135714
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135714
18 years
[Design of EJB 3.0] - Re: webservices ejb3 api usage
by heiko.braun＠jboss.com
Here's my 2 cents on invocation handling:
Currently we use
| SessionContainer.localInvoke(method, args, null, callback)
|
and the callback impl. supplies the WebServiceContext to the BeanContext.
However the biggest problem with this approach is that the bean context doesn't have a generic way of supplying context properties. This currently forces us to cast to a particular beancontext (StatelessBeanContext).
I think if we want to stick with that approach, we need to solve to problems:
1) How to get to a container in the first place?
2) How to inject a webservice context in a generic way?
The first point currently relies in the ObjectName for that container and uses an aop Dispatcher to to get to the container. IMO both is crap and should be replaced by proper abstractions.
The second point can be solved two ways: Either the WS callback does the injection on it's own using reflection (2.1) or the BeanContext offers a more generic way to supply injectable properties (2.2), so that we are not forced to cast to particular container implementations.
I would favor 2.2, since dependency injection is already part of the EJB3 domain.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135711#4135711
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135711
18 years
[Design of JBoss jBPM] - Re: iCalendar wrapper
by tom.baeyens＠jboss.com
kukeltje, you exactly describe how jpdl should expose it. one option (as we did it before) is to put all those kind of components in the jpdl project.
jbpm can integrate with about anything. keeping all those library dependencies manageable is difficult. some of these integrations like email, jcr and probably ical require whole specific test environments.
merging all of that into the jpdl project can become a problem. that's why i'm thinking of extracting it into separate projects.
but jpdl will still just use it and expose those features as it pleases.
and it's definitely not decided yet. it might go as well into the jpdl subproject directly. i'm just sketching the context so that you (and all other readers) can shed their light on this topic
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135704#4135704
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135704
18 years