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

[Design of JBoss jBPM] - Re: [sim] Configuration of Experiment

by camunda

OK, I think the main direction is more or less clear at the moment. Thanks for your remarks! I wrote a short article about my first language proposal. For this, I included everything in the process definition, but I can imagine to "outsource" the resource-pool & distribution elements (or to allow overriding them from the outside). For comments on the concrete language, I start an own thread in a minute. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092465#4092465 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092465

18 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: [sim] Configuration of Experiment

by tom.baeyens＠jboss.com

here's what i would do: create 1 language that is embedded in the process definition xml. but design your language in such a way that the amount of information inside the nodes or other elements is limited. if more information is required, refer to something that is defined in the process definition level. similarly to e.g. swimlanes. then you can still define a kind of import of a process archive resource so that most of the big complex building blocks of the simulation information are potentially defined in an external file, but that the link between those externally defined entities and the process definition elements is right inside elements in the processdefinition.xml makes sense ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092450#4092450 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092450

18 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Maven Documentation

by wesleyhales

Thanks Anders, you have been a great help. Keep the suggestions and ideas coming! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092374#4092374 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092374

18 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Read and write to a text file on jboss server using web serv

by aparitala＠gmail.com

We are trying to develop console application, and we want to write a web service method using java to read and write the properties to a text file, could any one can help us we really appreciate. Thanks, Anji View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092371#4092371 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092371

18 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: [sim] Configuration of Experiment

by kukeltje

why XML? Tom even blogged about a non-xml based version of a processlanguage (can't find the entry at the moment). Besides that, I agree with all the rest of your remarks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092346#4092346 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092346

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Getting runtime component name from attachment

by alesj

"alesj" wrote : | Or it can already be a part of @ManagementRuntimeRef. | Transformer hooko added to the annotation. And we also check if a transformer was registered for the PropertyInfo.getType in AbstractManagedObjectFactory. "alesj" wrote : | I think we can have a common interface which both MO and MC would extend, stripping some details from MC. | I'll push in the initial common interface, and you can still refactor it later. I added ManagedCommon (not very inspired name). It holds propertys that looked to me that could belong to both interfaces + getting the tests pass. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092295#4092295 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092295

18 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: When is there an EJBObject?

by ALRubinger

I'm not sure the history of our goals in implementation, but taking from the perspective of an application developer: Isn't the concept of "partially-realized" confusing? An EJB2.1 view that's only callable from a EJB3.0 client? Why? An EJB should have the following possible views: EJB3.0, EJB2.1, or both, with nothing inbetween. Anything half-defined should throw a descriptive Exception to the bean provider on deploy. Propose the following: * Close 1058 as invalid/not a bug * Fix RemoteUnitTestCase.testEJBObject() to pass by changing org.jboss.ejb3.test.stateful.Stateful to extend EJBObject. * Open a new issue, redefining the case outlined in 1058 but stipulating that the container should throw an exception on deploy. Remote interface w/ no home is an incomplete 2.1 view. * Open a new issue for the inverse: Home interface with no Remote interface is an incomplete 2.1 view. Benefits here: * We don't have to guess/infer what the intent of the bean provider was to expose * We give clear failures on deployment as to why an EJB with partially-implemented 2.1 views to the bean provider. Invite those with more experience w/ Spec interpretation to invalidate this argument. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092280#4092280 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092280

18 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: When is there an EJBObject?

by wolfc

In the failing unit test a proxy to a bean with a remote business interface is cast to an EJBObject. So we can agree that this is in fact an illegal construct? We can still allow a home-less bean with a remote interface. It would result in a partially realized EJB 2.1 view, only usable by EJB 3 users. (EJBTHREE-1058) I say for fully realized EJB 2.1 view you must have: - a home interface (extending EJBHome or EJBLocalHome) - a remote/local interface (extending EJBObject or EJBLocalObject) A home interface without a remote/local interface would then be considered an illegal construct and should throw an exception at deployment time. Same goes for returning some else that the defined remote/local interface from the home's create method(s). In theory we could infer the remote/local interface from the home interface create method's return type. So an explicit remote/local interface definition is then optional. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092269#4092269 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092269

18 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: @XmlElementWrapper/@XmlElements

by scott.stark＠jboss.org

I worked around this by adding support for using JBossXmlChildren with a non-collection type: | @XmlType | @JBossXmlChildren | ({ | @JBossXmlChild(name="int", type=Integer.class), | @JBossXmlChild(name="float", type=Float.class), | }) | public class Bar | { | private Number value; | | public Number getValue() | { | return value; | } | | public void setValue(Number value) | { | this.value = value; | } | } | There was a TODO for this in JBossXBNoSchemaBuilder. The restriction is that the type must have a value property to accept the child value. The logic for the XmlElementWrapper seems incorrect for a property with XmlElements. The XmlElementWrapper Sequence should wrap the XmlElements Choice I believe? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092266#4092266 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092266

18 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Transaction Sticky LB policy for 4.2/trunk

by galder.zamarreno＠jboss.com

After finishing implementing jbas-4455 for JRMP, I have just started with unified invokers and I have realised that UnifiedInvokerProxy/UnifiedInvokerProxyHA maintain a instance reference to the InvokerLocator/Client instances to a specific invocation is using. That is, when a new target is chosen, the unified proxy updates its Client and corresponding InvokerLocator instances (if they've changed), and uses the Cient instance variable to make the call. As far as I can see there's no synchronisation in the usage/assignment of Client or InvokerLocator. Proxies are meant to be thread safe which means that multiple client app threads could be using the same proxy without any problems. I can see all this going wrong the moment someone uses client proxies this way in a clustered environment with round robin load balance policy. We've got no guarantee that round robin will work correctly in these situations. JRMP based invokers never had this problem because they never stored the target server invoker used as instance variable. Why should Unified invoker proxies do so? IMO, it shouldn't. In a clustered environment, such instance variable could be constantly changing, i.e. round robin. Secondly, looking at FirstAvailable, electedTarget access/update is not synchronised, however, the chances of having some issues are very small. First, the proxy needs to be shared by various threads before the electedTarget has been set, but as electedTarget already elected randomly, the secondary effects of this lack of safety are none. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092261#4092261 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092261

18 years, 6 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 October 2007