[jBPM Development] - ClassCastException using configuration.buildProcessEngine()
by ricardo delarosa
ricardo delarosa [http://community.jboss.org/people/rdelarosa] created the discussion
"ClassCastException using configuration.buildProcessEngine()"
To view the discussion, visit: http://community.jboss.org/message/536429#536429
--------------------------------------------------------------
Hi,
I am trying to obtain a reference to a "ProcessEngine" with the following code:
----------- starting code -----------------
org.jbpm.api.ProcessEngine processEngine = null ;
Configuration configuration = new Configuration();
// build a process engine from a configuration
try {
processEngine = configuration.buildProcessEngine(); /* ManejadorJBPM4.java:360 */
}
catch(java.lang.Exception exc) {
exc.printStackTrace();
}
----------- ending code -----------------
But the following exception is printed on the console:
17:47:29,171 ERROR [STDERR] java.lang.ClassCastException: org.jbpm.pvm.internal.
processengine.ProcessEngineImpl cannot be cast to org.jbpm.pvm.internal.processe
ngine.ProcessEngineImpl
17:47:29,171 ERROR [STDERR] at org.jbpm.pvm.internal.cfg.ConfigurationImpl.b
uildProcessEngine(ConfigurationImpl.java:81)
17:47:29,171 ERROR [STDERR] at org.jbpm.api.Configuration.buildProcessEngine
(Configuration.java:105)
17:47:29,171 ERROR [STDERR] at co.com.gestiontek.supercade.util.ManejadorJBP
M4.iniciarProceso(ManejadorJBPM4.java:360)
17:47:29,171 ERROR [STDERR] at co.com.gestiontek.supercade.action.workflow.R
egistroTramite.iniciarTramiteEnrolamiento(RegistroTramite.java:354)
17:47:29,171 ERROR [STDERR] at co.com.gestiontek.supercade.action.workflow.R
egistroTramite.iniciarTramite(RegistroTramite.java:292)
17:47:29,171 ERROR [STDERR] at co.com.gestiontek.supercade.action.workflow.R
egistroTramite.registrarTramite(RegistroTramite.java:228)
....
Excuse me, but I don't understand why there is a "ClassCastException" due to a casting from
org.jbpm.pvm.internal.processengine.ProcessEngineImpl to the same class ?
Any help is very appreciated.
Ricardo De la Rosa
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536429#536429]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion
"To scope or not to scope (domain.xml)"
To view the discussion, visit: http://community.jboss.org/message/536393#536393
--------------------------------------------------------------
> Jason Greene wrote:
>
> Jason Greene wrote:> > When you think about it, a server-group, and a cluster are really the same thing, the only difference is that the cluster has an additional set of services that a basic group does not.
> >
> > Yes, but isn't the set of capabilities that a server has defined by its profile? We could say that defining a server as part of a cluster means that additional capabilities are added beyond what's in the profile. But then we are dividing the definition of a profile into two places. Also, exactly what capabilities should be added if a server is in a cluster is unclear.
>
> I think this depends on the definition of a profile. To me our previous definition of profile focused much more on internal implementation details (how to build a server with ejb3 (which jars etc)). When I look at the domain model I am looking at it from a configuration standpoint. Specifying things like "jndi should be clustered on port blah blah blah". There should be a thread pool with X threads, etc
The part of our existing profile discussion I was thinking of was what's shown here: http://community.jboss.org/docs/DOC-14742 http://community.jboss.org/docs/DOC-14742. Basically a fairly compact listing of required capabilities, an indication of where a deploy directory is (which could perhaps be defaulted). Then add stuff like jdbc-resources, jms-resources, threads, etc. That's pretty end-user-oriented; the heavy implementation detail stuff is in http://community.jboss.org/docs/DOC-14743 http://community.jboss.org/docs/DOC-14743.
If we didn't need the required capabilities bit (e.g. could infer them from the rest of domain.xml content), that's nice. But I don't know if we can do that, not if we allow a deploy dir with contents not fully specified in domain.xml.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536393#536393]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
[Management Development] - ProfileService SPI impacts of domain.xml
by Scott Stark
Scott Stark [http://community.jboss.org/people/scott.stark%40jboss.org] created the discussion
"ProfileService SPI impacts of domain.xml"
To view the discussion, visit: http://community.jboss.org/message/536388#536388
--------------------------------------------------------------
I want to fork off a thread to discuss the impacts of the domain.xml work on the profileservice SPI and implementation. A starting point is the IOC issue Emanuel raised. Here is a bootstrap based on a question I asked him about what his concern was:
> Emanuel wrote:
>
> On 04/08/2010 05:16 PM, Scott Stark wrote:
> > I want to understand that problem in detail as it does matter. In terms
> > of the domain model, even the scope of property values we support I
> > imagine will be limited unless we are going to support the full
> > BeanMetaData in the domain model.
> >
> > So, your talking about when a property has an injection value, we don't
> > know the real value because there is no runtime? It's only when the
> > final configuraiton stage of the MC is running that the true value is
> > known?
> >
>
> Yes, we need installed beans to get a hold of the target. Given aliases and all dynamic injection features MC has - also there is no guarantee that the injected value is actually a ManagedObject.
>
> On top of this you have the @XmlAnyElement callback for BeanMetaDataFactories in the KernelDeployment, which does not really simplify this ;)
> > In terms of configuration, the configuration value is a reference to
> > something else. The actual value is not knowable until runtime, and I
> > don't see that this can be avoided as a service-configuration vs
> > runtime-service. What are you thinking?
> >
>
> Yes, the configuration should be a reference. Where the configuration is the MO, the service the consumer - where you basically change:
>
> <bean name="service>
> <property name="timout">5</property:
> <property name="injectedBean"><inject name="injectedService"/>
> </bean>
>
> into:
>
> <bean name="service">
> <property name="timeout"><inject name="configuration" property="timeout" /></property>
> <property name="injectedBean"><inject name="injectedService"/>
> </bean>
>
>
> So just a brief pseudo-code how persisted changes are applied:
>
> @ManagementObject(component=...)
> public class Service
> {
> @ManagedProperty
> int timeout();
>
> @ManagedProperty
> InjectedService getInjectedService()
> }
>
> <bean name="service">
> <property name="timeout">5</property>
> <property name="injectedService"><inject name="injected-service"/></..>
> </bean>
>
> by default you get:
>
> SimpleValue timeout = mc.getProperty("timeout");
> CompositeValue composite = mc.getProperty("injected-service");
>
> The persistence does:
>
> <component name="service">
> <property name="timeout>5</property>
> <property name="injectedService">
> <composite type="org.jboss.test.InjectedService">
> <item name="" ...>
> </composite>
> </property>
> </component>
>
> When we restore the information we do:
>
> BeanMetaDataBuilder.setProperty("injectedService", metaValueFactory.unwrap(compositeValue));
>
> This is what basically happens for service-binding-manager:
> http://svn.jboss.org/repos/jbossas/trunk/server/src/etc/conf/all/bindings... http://svn.jboss.org/repos/jbossas/trunk/server/src/etc/conf/all/bindings...
>
> So in case "injectedService" is complex - e.g. no default constructor, this is going to fail.
>
>
> Ok, this looks a bit messy in the email - i can also write a testcase and explain more in case something is unclear.
>
I don't see that it is practical to have the original deployment state an indirection on some configuration object, so what you mean is that when we override the property value, we are doing so with an injection to a property in the domain configuration metadata object.
One of the changes we have to make to the profileservice ManagedObject implementation is to have a seperation from the runtime and configuration. The configuration is the unresolved BeanMetaData with only simple values and injection references. We cannot query the runtime state of the runtime component. Access to runtime values and operations is a seperate aspect from the configuration.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536388#536388]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion
"To scope or not to scope (domain.xml)"
To view the discussion, visit: http://community.jboss.org/message/536382#536382
--------------------------------------------------------------
> Brian Stansberry wrote:
>
> > Jason Greene wrote:
> > When you think about it, a server-group, and a cluster are really the same thing, the only difference is that the cluster has an additional set of services that a basic group does not.
>
> Yes, but isn't the set of capabilities that a server has defined by its profile? We could say that defining a server as part of a cluster means that additional capabilities are added beyond what's in the profile. But then we are dividing the definition of a profile into two places. Also, exactly what capabilities should be added if a server is in a cluster is unclear
I think there is a definite overlap between the definition of a profile and the definition of a grouping. The only way I can see having both in domain.xml is to have the profile function as a template like you mention earlier (or to pull all common config stuff out of a group).
> > Jason Greene wrote:
> > When you think about it, a server-group, and a cluster are really the same thing, the only difference is that the cluster has an additional set of services that a basic group does not.
>
> Yes, but isn't the set of capabilities that a server has defined by its profile? We could say that defining a server as part of a cluster means that additional capabilities are added beyond what's in the profile. But then we are dividing the definition of a profile into two places. Also, exactly what capabilities should be added if a server is in a cluster is unclear.
I think this depends on the definition of a profile. To me our previous definition of profile focused much more on internal implementation details (how to build a server with ejb3 (which jars etc)). When I look at the domain model I am looking at it from a configuration standpoint. Specifying things like "jndi should be clustered on port blah blah blah". There should be a thread pool with X threads, etc
> A very simple concept of a cluster is that it is a server-group that also exposes some predefined configuration properties that need to be kept consistent throughout the group. (A server-group would not have such properties by default, although users could add custom ones.) Things such as:
>
> * Group name (current -g)
> * Type of intra-group communication to use by default (udp, tcp)
> * Default interface to use for intra-group communication
> * Default multicast address to use
> * other defaults less commonly changed
>
>
Right this is exactly what I was getting at. It also would represent what resources are available (datasources etc).
>
> A cluster might also have some management capabilities besides what is available to a server-group, although I'm not sure what. It should be possible for example to perform a (rolling) redeployment to a server-group.
>
> A separate discussion is how communication will occur between servers who are not members of a cluster. There needs to be a group communication mechanism that spans the entire domain.
I think the best way to address this is that everything in a domain will have two communication services that are distinct from everything used in clustering:
1. Configuration syncing
2. Deployment
These services could be implemented in a number of ways, but will likely need to be a simple/specialized protocol. It might even necessitate a node agent of some sort. However I think thats a conversation for later, the important thing is the notion that synching must be possible to non-clustered nodes.
> > This was what I meant by the cluster-service tag, a way to specify how a group would cluster a particular service (maybe not all services should be clustered). Although it was just something I through out there as an example. A better way likely exists
>
> Currently how we cluster a particular service is defined in that service's configuration, it's not something applied externally. And the details of what needs to be configured are often disparate between different services, so I'm not sure those configs can profitably be externalized into some common configuration element.
>
> Ah, or are you talking about "clustered-service" as a wrapper to describe how to manage the service, e.g. how to (re)deploy across cluster?
Don't read too much into it, it was just a generalization. Substitute clustered-service with "jgroups-group" or "ha-jndi".
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536382#536382]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion
"To scope or not to scope (domain.xml)"
To view the discussion, visit: http://community.jboss.org/message/536377#536377
--------------------------------------------------------------
> Scott Stark wrote:
>
> > Brian Stansberry wrote:
> >
> > Since we're in the mode of defining things, what is a "multi-domain notion?" I see it as a an ability to manage within the same tool multiple sets of servers where each set has it's own management policy. The sets of servers are conceptually distinct (hence the separate management policy / domain) but, generally for operational ease of use reasons, users wish to manage multiple domains from the same tool.
> >
> Right, which is why I don't see this as impacting what the domain.xml looks like. This notion exists above the servers and profileservice. We are told what domain we are operating in.
In the discussion we had at the OA&M meeting with the JON folks, we thought that the AS perspective of management ends with the domain . "Multi-domain" management was something that JON would offer, as a compelling difference. So our admin console, cli, and domain.xml interfaces would be limited to a domain. I still think this is the "right" approach.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/536377#536377]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month