[jBPM Development] - HELP ME with process Java
by cmjhingeniero
Hi
I'm using jBPM-4.2 with Tomcat and PostgreSQL. I have the following process, that the only thing it does is print a message Hello World. When I run an instance of the process I get the following error, and I want to know if some configuration or covered
| URL: 'http://localhost:8080/gwt-console-server/rs/process/definition/Java-1/new...'
| Action: 'org.jboss.bpm.console.client.process.StartNewInstanceAction'
| Exception: 'class com.google.gwt.http.client.RequestException'
| HTTP 500: Unknown error
|
Proceso:
| <?xml version="1.0" encoding="UTF-8"?>
| <process name="HolaMundo" xmlns="http://jbpm.org/4.0/jpdl">
| <start name="start1" g="81,123,48,48">
| <transition name="to java1" to="java1" g="-45,-18"/>
| </start>
| <java name="java1"
| class="com.procesos.holamundo.Mensaje"
| method="hola"
| g="170,122,92,52">
| <field name="mensaje"><string value="HOLA MUNDO"/></field>
| <arg><string value="jBPM"/></arg>
| <transition name="to end1" to="end1" g="-42,-18"/>
| </java>
| <end name="end1" g="304,123,48,48"/>
| </process>
|
Gracias
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265500#4265500
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265500
16 years, 4 months
[Management Development] - Re: Simple Example using ManagedObjects and ProfileService
by emuckenhuber
"rareddy" wrote : Adding the "isRuntime=true" did the trick, now I see profile service invoking the bean correctly. Thank you.
|
Ok, good - btw... isRuntime will also fetch the new value of managedProperties with ViewUse.Statistic when getValue() is called. Otherwise the value is set once ManagementView is loaded, which is used for configuration properties.
"rareddy" wrote :
| I see that only beans that have @ManagementObject annotation + deployed through bean deployer (thru -jboss-bean.xml) file are accessible through the profile service. Is there a way I can build a bean with @ManagementObject annotation but initialized through "new myBean()", some how injected into managed objects collection?
Hmm, this is difficult to say since i don't really know what you are trying to achieve and the expected behavior for ProfileService. In general we create ManagedObjects based on the attachment meta data in the deployers. So in case you have your own deployers you should be able to explicitly add and expose your ManagedObjects, which is the preferred way.
Maybe you want to briefly describe what you would like to do and how your integration code works.
Thanks,
Emanuel
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265486#4265486
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265486
16 years, 4 months
[Management Development] - Re: Management of user deployment objects
by emuckenhuber
when you are talking about <config-property /> i guess this refers to the List in the MCFDMD right?
This should be exposed as a collection of CompositeValue (which is basically a restricted Map) - this should be generated by default. The only thing which should be added is a @CompositeKey annotation on the getName() to declare this as index.
Maybe it should even be a TableValue, since this could simplify looking up values in a unit tests. I can look into providing a MetaMapper for this at one point. Although the default format should work for the console as well.
Looking at the way it's done atm does not make much sense and basically hacks itself. There were some discussions before to expose this in a different way, since the console could handle a compositeType better.
In case you want to try that out you would need to annotate the MCFDMD with @ManagedObject and use the ManagedObjectFactory to initialize the ManagedObject. We are also going to provide a xml meta data format to describe ManagedObjects/Components - so that you don't necessarily need to depend on jboss-man.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265484#4265484
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265484
16 years, 4 months
[JBoss OSGi Development] - Re: No explicit control over bundle.start()
by alesj
"thomas.diesler(a)jboss.com" wrote :
| The MC Framework incorrectly uninstalls the bundle if there is a failure in bundle.start()
|
No, that is / should be the right behavior, as you don't wanna have broken service stuck in some middle state.
The is a notion of ErrorHandler in Controller, which might be useful,
if we decide to go down this path.
Imho, the real problem is how we handle this Bundle::start.
"thomas.diesler(a)jboss.com" wrote :
| The controller context reached its required stage DESCRIBED after bundle install. A subsequent call to bundle.start() is supposed to transition to stages CLASSLOADER and then INSTALLED, which corresponds to the Bundle states RESOLVED and ACTIVE respectively.
|
Bundle::start should only be called after we're past CLASSLOADER stage.
At least in automated mode. If the user wants to do this before, it's his choice and potential fault.
"thomas.diesler(a)jboss.com" wrote :
| Adrian, this seems to be a fundamental problem for which neither Ales nor I could come up with a solution. Could you perhaps have a look at this issue.
|
Actually I solved it in some hackish way.
Afair, my problem was that I didn't know how to resolve cyclic bundles,
but that's actually Controller's resolve problem as it doesn't know how to resolve cyclic dependencies in the same state.
But yeah, I'm all for it that Adrian gets a stab at this problem. :-)
* Bundle:start issue
* cyclic bundle dependencies
* resolve algorithm performance issue (EmanuelM has a good example of this)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265455#4265455
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265455
16 years, 4 months
[JBoss OSGi Development] - Re: Handle potential bundle:// protocol with VFS
by alesj
"thomas.diesler(a)jboss.com" wrote : Anybody can do
|
| | InputStream is = sysContext.getBundle(someId).getResource("/some-resource.txt").openStream()
| |
|
No.
e.g.
* I don't have access to system bundle / context -- remember your KernelLocator hack ;-)
* I don't wanna depend on OSGi api -- my code is 100% portable
"thomas.diesler(a)jboss.com" wrote :
| What is the use case where the URL format actually matters?
|
OK, you could use direct vfsx protocol, but then. like I alredy said, you're by-passing bundle's restrictions.
Instead you pass around bundle protocol based url, knowing the restrictions apply.
User could still of course do direct access, but the framework shouldn't encourage him to do so,
hence a custom protocol that works more closely with the framework.
Currently this is a simple prototype, but I guess this could/will come in handy when you need to pass resource access around
to other pieces of the OSGi env; e.g. compendium, your interceptors, ...
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265428#4265428
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4265428
16 years, 4 months