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

[Design of JBoss jBPM] - Re: process patch files

by david.lloyd＠jboss.com

That's a novel approach - but I think there is one main problem with it as suggested: we don't want users to actually be able to change the graph structure of their existing process (more specifically, anything that we consider to be static in the process definition) - we want them to be able to change *anything else* but that (like classes, extra process files [like images] or auxiliary XML data like GPD information). Maybe there could be a way to provide a process patch where just classes and files are provided, and changes to the XML that are not related to graph structure. Maybe a separate schema/DTD for updates that can clearly express this requirement. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052592#4052592 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052592

18 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Shutdown of controller

by alesj

"alesj" wrote : | But I'll have a look what can be done with the current code. I was able to handle this by introducing parent Controller to AbstractController. This piece of code does the trick. | AbstractController parent = getParentController(); | while (parent != null) | { | try | { | parent.unregisterControllerContext(context); | } | catch (Throwable t) | { | log.warn("Error unregistering context in parent controller: " + context.toShortString() + " with name: " + name); | } | parent = parent.getParentController(); | } | And it is legit, since duplicated names are detected while registering, so this code doesn't remove anything it shouldn't. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052590#4052590 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052590

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: moving to repository.jboss.org

by david.lloyd＠jboss.com

I talked to Paul Gier and you are correct, it will be .org from now on. Guess I'm the one who is confused. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052586#4052586 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052586

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Classloader leak via CacheImpl.invocationContextContaine

by bstansberry＠jboss.com

There absolutely needs to be some mechanism for clients to set Option flags on calls via the Cache API. Pretty much all AS uses of JBC would fail w/o that. Agreed though that InvocationContext exposes more than a client should be able to tweak. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052585#4052585 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052585

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Classloader leak via CacheImpl.invocationContextContaine

by jason.greene＠jboss.com

I know we are too late in the game for API changes but... If the InvocationContext is only available for one call, then does it really make sense to expose this as a public API? Wouldn't it be more sensible to make this part of CacheSPI? There are a lot of options here that would be pretty hazardous to mess with. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052581#4052581 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052581

18 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - wstools error in wsdl2java

by johnefranklin＠yahoo.com

Hi, I am attaching a wsdl that used to work nicely with JBoss 4.0.5. But when I try to generate the java files from the wsdl using the wstools shipped along with JBoss 4.2, it keeps giving me this error. Exception in thread "main" org.jboss.ws.WSException: [JAX-RPC 2.3.1.2] Unable to unwrap model group with multiple particles. at org.jboss.ws.tools.helpers.ReturnTypeUnwrapper.unwrapModelGroup(ReturnTypeUnwrapper.java:120) at org.jboss.ws.tools.helpers.ReturnTypeUnwrapper.unwrap(ReturnTypeUnwrapper.java:87) at org.jboss.ws.tools.WSDLToJava.getReturnType(WSDLToJava.java:632) at org.jboss.ws.tools.WSDLToJava.appendDocParameters(WSDLToJava.java:395) at org.jboss.ws.tools.WSDLToJava.appendMethods(WSDLToJava.java:290) at org.jboss.ws.tools.WSDLToJava.createSEIFile(WSDLToJava.java:588) at org.jboss.ws.tools.WSDLToJava.createSEI(WSDLToJava.java:618) at org.jboss.ws.tools.WSDLToJava.generateSEI(WSDLToJava.java:186) at org.jboss.ws.tools.helpers.ToolsHelper.handleWSDLToJavaGeneration(ToolsHelper.java:303) at org.jboss.ws.tools.WSTools.process(WSTools.java:137) at org.jboss.ws.tools.WSTools.generate(WSTools.java:69) at org.jboss.ws.tools.WSTools.generate(WSTools.java:119) at org.jboss.ws.tools.WSTools.main(WSTools.java:58) Can someone please look at the wsdl and point me the problem in the wsdl? regards, johnf | | <definitions name="EventMonitoringService" targetNamespace="http://com.ws.test/sample" | xmlns="http://schemas.xmlsoap.org/wsdl/" | xmlns:ns2="http://com.ws.test/sample" | xmlns:tns="http://com.ws.test/sample/types" | xmlns:xsd="http://www.w3.org/2001/XMLSchema" | xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" | xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" | xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"> | <types> | <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" | targetNamespace="http://com.ws.test/sample/types" | xmlns:tns="http://com.ws.test/sample/types"> | | <xsd:simpleType name="DeviceID"> | <xsd:restriction base="xsd:string"> | <xsd:minLength value="0"/> | </xsd:restriction> | </xsd:simpleType> | | <xsd:complexType name="LogicalEvents"> | <xsd:sequence> | <xsd:element name="logicalVar1" type="xsd:boolean" minOccurs="0"/> | <xsd:element name="logicalVar2" type="xsd:boolean" minOccurs="0"/> | </xsd:sequence> | </xsd:complexType> | | <xsd:complexType name="PhysicalEvents"> | <xsd:sequence> | <xsd:element name="physicalVar1" type="xsd:boolean" minOccurs="0"/> | <xsd:element name="physicalVar2" type="xsd:boolean" minOccurs="0"/> | </xsd:sequence> | </xsd:complexType> | | <xsd:complexType name="FilterEvents"> | <xsd:sequence> | <xsd:element name="physical" type="tns:PhysicalEvents" minOccurs="0"/> | <xsd:element name="logical" type="tns:LogicalEvents" minOccurs="0"/> | </xsd:sequence> | </xsd:complexType> | | <xsd:simpleType name="ErrorValue"> | <xsd:restriction base="xsd:string"> | <xsd:minLength value="0"/> | </xsd:restriction> | </xsd:simpleType> | | <xsd:complexType name="TestException"> | <xsd:sequence> | <xsd:element name="errorValue" type="tns:ErrorValue"/> | <xsd:element name="errorMessage" type="xsd:string" nillable="true"/> | </xsd:sequence> | </xsd:complexType> | | <xsd:element name="ErrorValue" type="tns:ErrorValue"/> | <xsd:element name="TestException" type="tns:TestException"/> | | <xsd:element name="MonitorEventsRequest"> | <xsd:complexType> | <xsd:sequence> | <xsd:element name="deviceID" type="tns:DeviceID"/> | <xsd:element name="requestFilter" type="tns:FilterEvents" minOccurs="0"/> | </xsd:sequence> | </xsd:complexType> | </xsd:element> | | <xsd:element name="MonitorEventsResponse"> | <xsd:complexType> | <xsd:sequence> | <xsd:element name="deviceID" type="tns:DeviceID"/> | <xsd:element name="allotedFilter" type="tns:FilterEvents" minOccurs="0"/> | </xsd:sequence> | </xsd:complexType> | </xsd:element> | </xsd:schema> | </types> | | <message name="MonitorEventsRequest"> | <part name="parameters" element="tns:MonitorEventsRequest"/> | </message> | | <message name="MonitorEventsResponse"> | <part name="result" element="tns:MonitorEventsResponse"/> | </message> | | <message name="TestException"> | <part name="exception" element="tns:TestException"/> | </message> | | <portType name="EventMonitoringService"> | <operation name="MonitorEventsRequest"> | <input message="ns2:MonitorEventsRequest"/> | <output message="ns2:MonitorEventsResponse"/> | <fault name="FaultName" message="ns2:TestException"/> | </operation> | </portType> | | | <binding name="EventMonitoringServiceBinding" type="ns2:EventMonitoringService"> | <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/> | <operation name="MonitorEventsRequest"> | <soap:operation soapAction=""/> | <input> | <soap:body use="literal"/> | </input> | <output> | <soap:body use="literal"/> | </output> | <fault name="FaultName"> | <soap:fault name="FaultName" use="literal"/> | </fault> | </operation> | | </binding> | <service name="EventMonitoringService"> | <port name="EventMonitoringServicePort" binding="ns2:EventMonitoringServiceBinding"> | <soap:address location="http://localhost/test/EventMonitoringService"/> | </port> | </service> | | </definitions> | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052557#4052557 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052557

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: moving to repository.jboss.org

by alex.guizar＠jboss.com

David, the source of the confusion might be Paul Gier's email: anonymous wrote : The web site for downloading artifacts (http://repository.jboss.com) is also now available at http://repository.jboss.org. The old URL http://repository.jboss.com will still be available, but please be aware that this URL will eventually go away, so references to this site should be updated. You are right in that both repository.jboss.com and repository.jboss.org point to the same location now, but if I understand correctly, the URL that will go away is repository.jboss.com. Perhaps I missed something? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052555#4052555 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052555

18 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Shutdown of controller

by alesj

I'm adding some shutdown tests. "alesj" wrote : "adrian(a)jboss.org" wrote : | | Ales, can you check the child controller shutdown code is ok? | It looked OK when I looked it before this post, but I'll check again. :-) Nope, it doesn't work as it should. :-( But the problem is not in the shutdown code, it's the uninstall by name of scoped beans with the same name - since they eventually get pushed back to underlying Controller on the Pre_Install state. And when another one with the same name is pushed, we get a 'name already exists', as expected. So basically this uninstall of scoped beans didn't work as it should even before the shutdown code. But before I didn't see it since we were uninstalling context from the underlying Controller, drilling down to child Controllers. Shutdown does this just the other way around. This can all be solved with the GUID naming we talked about doing. But I'll have a look what can be done with the current code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052553#4052553 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052553

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: gravel 1.0.0-SNAPSHOT does not exist in the remote repos

by david.lloyd＠jboss.com

My apologies, I forgot to commit this change last night before going to bed. Yes, CR1 is the proper version for Gravel. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052544#4052544 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052544

18 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: moving to repository.jboss.org

by david.lloyd＠jboss.com

Alex, you are confused. The NEW site is repository.jboss.com, and in actual fact repository.jboss.com and repository.jboss.org BOTH point to the SVN repository. The message was that repository.jboss.org would eventually go away, which is why I switched to repository.jboss.com some weeks ago. Please revert the change. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052543#4052543 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052543

18 years, 10 months

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 June 2007