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

[Design of POJO Server] - Re: Questionable, but working, fix for JBMETA-83

by scott.stark＠jboss.org

That seems an unlikely scenario, when would I base the ejb name on the ear name? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166804#4166804 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166804

17 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - How does version.properties get copied

by timfox

Ok, I am probably being stupid here, but I can't work this out. In src/config we have a file version.properties which gets copied to build/classes before the jar is built using ant jar. But I can't find the line in the ant script which does the copy. It's like it gets there by magic, any ideas? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166800#4166800 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166800

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by tom.baeyens＠jboss.com

I don't think that I do a bad job in analysing and predicting the BPM markets. If you look at this article from Miko Matsumura. http://www.soacenter.com/?p=163 Especially the part about The âMagic Cure for BPMâ Business analysts Rejoice!, expresses the current mainstream thinking about BPEL. Exactly those thoughts I have been expressing constantly for the last for years. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166789#4166789 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166789

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by tom.baeyens＠jboss.com

"heiko.braun(a)jboss.com" wrote : anonymous wrote : | | The mismatch in naming of workflow elements is nearly as bad as it can get... | | | | I totally agree with this. This was the reason for looking at BPMN in the first place. We wanted to get to "proven concepts" with "established terminology". | BPMN is not a proven concept. Look at the discussions around BPMN 2.0 and you'll see that the future if far from clear or stable. Second, it is a analysis modelling notation with focus on the business analyst. For the terminology part, that is not a good basis for an executable process language. I agree with Ed's comment later on that BPMN terminology is not a good basis for the API. "heiko.braun(a)jboss.com" wrote : | And to be honest, following the discussions around BPMN and executable dialects, I still don't see arguments why it can't be done. Please show me examples of BPMN elements that conflict with execution. | Adding a runtime interpretation to BPMN modelling constructs is possible. But by doing that, you would limit the use of BPMN for its original purpose: analysis modelling. Because when all BPMN constructs have a runtime interpretation, that means that an analyst can not model freely any more. When he/she draws a certain box, he/she has to be aware of the implications when this process is being executed on a computer system. Which eventually will limit BPMN to graphical programming. It is impossible to create an executable process language so that non tech analylsts can model in all freedom and which aftwards turns out to produce exactly the right software. There must be a mapping between analysis and executable process language. The easiest and most practical way to do this is by introducing a one-way translation between BPMN and jPDL. That way BPMN can keep its focus on being a modelling notation for non tech business analysts. And jPDL can keep its focus on being an executable process language that developers can use to produce the same diagram as the analysis model. "heiko.braun(a)jboss.com" wrote : | IMO it's not necessary to have full BPMN support. We just need those parts that we actually can make executable. If I remember correctly BPMN even defines profiles with different scopes. But I think a 60% BPMN support is still better 100% jPDL, which is, by the way, something we cannot even easily compare at the moment, because jBPM doesn't use common BPM patterns and established terminology to express it's features/capabilities. The market doesn't have proven concepts that we can just follow and implement. Two years ago, BPEL was the well accepted standard for BPMN. One year ago, BPMN came into the picture. So everyone focussed on the impossible BPMN to BPEL mapping. Now, as people realize BPEL is best suited for service orchestration, BPEL is starting to fade away as a solution for BPM. Now, the battle for BPMN 2.0 shows that BPMN itself is not a proven concept. There is only 1 product in the BPM area that I have great respect for. IDS Scheer's ARIS. They take the inverse perspective of us. We start from an executable process language jPDL, and we try to bind it to the analysis world without compromise on the technical and executable side. IDS Scheer has by far the most advanced modelling environment, and they only go as far to bind it to implementation details as they can without compromise on the analysis side. All initiatives that try to combine both have been proven to be good only in a niche area. There is no technology that binds the 2 automagically and is able to be more then a niche product. @camunda: IDS Scheer has one of the best round tripping support out there. E.g. they can create graphical diffs of analysis models and calculate the impacted parts in the related executable process. But I think it does not fit our target. As it takes a huge development effort. And it also takes a great effort from to user to bind the analysis and implementation models and keep all of that in sync. I think the latter is only suitable in the very top range of use cases. I think that with a one-way translation from analylsis to implementation model, we can serve more then 90% of the use cases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166788#4166788 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166788

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing MC notion to Seam/ServletContext

by thomas.heute＠jboss.com

"scott.stark(a)jboss.org" wrote : Mapping mc beans to the web app attributes is a general aspect not specific to seam that could be used in jsf expressions, etc. And JBoss Portal View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166787#4166787 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166787

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: Pushing MC notion to Seam/ServletContext

by alesj

"scott.stark(a)jboss.org" wrote : Most of the jbossweb classes are configurable, so it could probably just be customization of the existing deployers. | Sure. :-) But which one is responsible for ServletContext creation? And does it have access to underlying MC and DeploymentUnit at the moment of initialization/creation? "scott.stark(a)jboss.org" wrote : | Mapping mc beans to the web app attributes is a general aspect not specific to seam that could be used in jsf expressions, etc. So we should make this default in JBossAS. And one could explicitly turn it off. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166785#4166785 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166785

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Questionable, but working, fix for JBMETA-83

by ALRubinger

https://jira.jboss.org/jira/browse/JBMETA-83 When a mappedName for an EJB is equal to the deplomentScopeBaseName (ie. EAR name), BasicJndiBindingPolicy will issue conflicts because the mappedName will have been bound, and hence become an invalid target for a SubContext as a base. So my solution was when these two properties match, append a "_" to the baseName and issue a warning to the user: 23:42:44,521 WARN [BasicJndiBindingPolicy] The EAR name, which is used as a base, is equal to the mappedName for EJB "AroundInvokeBean", to avoid JNDI Naming Conflict appending a '_' to the base JNDI name. [JBMETA-83] If anyone's got a more elegant idea, all ears. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166774#4166774 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166774

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService equiv to ServiceBindingManager

by bstansberry＠jboss.com

So this management interface for the binding manager becomes an abstraction that allows a management tool to configure all ports/interfaces in the server via a central location. Do you see this as providing the ability to update the ports of running components (assuming the component supports such a thing). That is, SBM currently updates interfaces/ports when an mbean is deployed. It has no ability to subsequently update the mbean. You could add a management interface to this to improve upon the -bindings.xml-based configuration without adding any ability to update installed components through it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166765#4166765 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166765

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService equiv to ServiceBindingManager

by bstansberry＠jboss.com

>From some off-line discussions: "bstansberry(a)jboss.com" wrote : | "scott.stark(a)jboss.org" wrote : | | ServiceBindingManager has to be replaced with a component that integrates with the profile service to use the management view. We have talked about having managment view properties support annotation so that they can be identified as ports, interfaces. With that, it should be easy to replace this. | | | | Not sure if the bit about annotating management view properties is needed (at least for a first version). The service names and relevant properties can be identified in a -bindings.xml file. | | If so, I'm thinking in terms of following the same architecture as the current SBM, where a microcontainer ControllerContextAction calls the SBM as part of bean configuration, passing the service name and the management view. The SBM at start has parsed a -bindings.xml and created a bunch of ServiceBinding objects. One the call from the ControllerContextAction, it looks up the ServiceBinding for the service name, finds a delegate, tells the delegate to apply the bindings. | | We'd need new versions of the 3 existing delegate classes that do much the same thing, but instead of updating mbean properties, they invoke setters on the management view. | | We'd also have to have proper management views for all the services involved in SBM: | | jboss:service=Naming | jboss:service=WebService | jboss:service=invoker,type=jrmp | jboss:service=invoker,type=pooled | jboss:service=HAJNDI | jboss:service=invoker,type=jrmpha | jboss:service=invoker,type=pooledha | jboss:service=CorbaORB | jboss.jmx:type=Connector,name=RMI | jboss.jmx:name=SnmpAgent,service=trapd,type=logger | jboss.jmx:name=SnmpAgent,service=trapd,type=adaptor | jboss:service=invoker,type=http | jboss:service=invoker,type=http,target=Naming | jboss:service=invoker,type=http,target=Naming,readonly=true | jboss:service=invoker,type=httpHA | jboss:service=invoker,type=http,target=HAJNDI | jboss.ws:service=ServiceEndpointManager | jboss.remoting:service=JMXConnectorServer,protocol=rmi | jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3 | jboss.remoting:service=Connector,transport=socket | jboss.web:service=WebServer | | Might be able to reduce that if we can keep the existing ability to use the mbean interface as the management view and update it via setting JMX attributes. | And Scott's response: "scott.stark(a)jboss.org" wrote : | A first pass implementation could simply have a mapping from the metadata class/property that is being bound and a deployer would update replace the component metadata before the component deployer runs. Both mbeans and mcbeans are in use for ports/interfaces now. I would think that should be easier than integrating with mc controller contexts. | | Providing a management interface for a binding manager and exposes the available ports/interfaces is what I was talking about in the forum. How that should be done stil needs some more thought. We should be providing a management interface that applies to whatever the initial implementation is and migrate that to the final implementation so that its relatively stable for users as it evolves. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166763#4166763 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166763

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: CNFE when using PojiProxy/Remoting

by ALRubinger

dynamicInvoke had the proper TCL set, problem is nothing was running through it because I'd removed registration of the Container with AOP via the ClassProxyHack: - Dispatcher.singleton.registerTarget(getObjectName().getCanonicalName(), new ClassProxyHack(this)); | + Dispatcher.singleton.registerTarget(getObjectName().getCanonicalName(), this); Where the ClassProxyHack has: public InvocationResponse _dynamicInvoke(Invocation invocation) throws Throwable | { | return container.dynamicInvoke(null, invocation); | } ...and this is what gives me my hook to set the proper TCL. >From here I've got the hooks I need to resolve this. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166758#4166758 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166758

17 years, 8 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 July 2008