August 2006 - jboss-dev-forums - Jboss List Archives

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: System property expansion with Multiplexer

by bela＠jboss.com

I thought variable expansion/substitution is a feature of JBoss, the subsystem parsing the config XML files ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964920#3964920 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964920

19 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Bean property inspection and actual injection

by alesj

What should be the right order of property wiring / bean injection? XML over @Inject? (as in ejb3) Is 'org.jboss.kernel.plugins.injection' right place to put some Injection utils? Rgds, Ales View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964919#3964919 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964919

19 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - batch-size of jbpm runtime objects

by tom.baeyens＠jboss.com

recently someone queried us about the batch size of the jbpm runtime objects and why they were not set to a proper default. based on Max's input on what batch-size on the class level actually is, i think that jBPM can't really define a good batch-size except the default for 1. "Max" wrote : | > | Is there a reason why batch-size isn't set to a reasonable default | > | on the various jBPM runtime objects? | > | > would that make sense ? | | depends. | | Let me see if i can explain this via pure email (i normally do fancy drawings and gestures to explain the voodoo-magic) | | Basically/naivelly speaking batch-size defaults to 1. | | Meaning that when Hibernate is asked to get some object by id from the db, e.g 42 it will try and load this single object by id 42. | | By increasing this on the class level to eg. <class name="Blah" | batch-size="5" ..> | then instead of just loading the one(1) matching the given id(42) hibernate will look in its cache and see if there is up-to 5 more non-initialized proxies that can be fetched. If there is hibernate will do something like "select ... from Blah where id in (42, 32, 4, 3, 17)" | instead of just id = 42. Hence optimally a reduction in requests to the db of factor 5. | | So, batch-size > 1 on classes make sense if you often have a bunch of un-initialized objects in the session that it would be relevant to get in batches of selects instead of single selects. | | The above is for class instances; but the same is valid for collections. | They too | have a batch-size option. This is not about getting a 20 element collection in e.g. 4 selects it is about loading multiple complete collections in fewer selects. | | The same logic as above applies. e.g. blah.getChildren() is internally viewed as "get the children collection for blah with id 42" (assuming blah's id is | 42 of course). | Here the default is to get that one collection, but alternatively Hibernate can look around and see if there are more uninitialized *collections* of the same role (Blah.children) and load those in one go. Again, this can be a very efficient optimization to e.g. load hiearchies of entities. | | There are alternatives such as fetch="subselect" which instead of using in | (x,y,z) creates | a sub query select based on what you just fetched. This requires a bit more drawings for me to explain (and i actually did that when you here - remember ? :) | | > should i have a look at what that is ? | | yes. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964917#3964917 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964917

19 years, 7 months

1
0
0 / 0

[Design of JBoss Profiler] - Problem starting profiler

by rufik

Hi, I have a problem starting JBoss with profiler: Linux 2.6.14 JBoss: 4.0.2 JVM: 1.5.0_07 JBoss Profiler RC4 What I did: 1. compiled libjbossInspector.so and libjbossAgent.so from /jvmpi-src/linux/compile.sh and /jvmti-src/linux/compile.sh 2. copy this .so to folder /profiler 3. export LD_LIBRARY_PATH=/profiler 4. add -Xrun:jbossInspector to run.sh (command line) And what? Error occurred during initialization of VM Could not find agent library on the library path or in the local directory: jbossInspector So, LD_LIBRARY_PATH is correct, I can see it. I tried `ldd /profiler/libjbossInspector.so` and result: not a dynamic executable I don't know - are this .so incorrect or something? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964916#3964916 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964916

19 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Variable type definition in processdefinition.xml (yes a

by tom.baeyens＠jboss.com

yes, variable type information is a good addition. we didn't really need it so far, but it would be nice to have. when we add it, we should make sure it doesn't become required information all of a sudden. we should try to keep the variable type information optional and maintain the hashmap idea of variables as a viable option. as for forms, the current status was that i didn't get types working with the 'conversion' property in JSF. i didn't try very hard, though so that would be the first thing to research. once that works, the automatic form generation that will be build by the gpd could use that information to generate the proper conversion in the task forms. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964913#3964913 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964913

19 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: debugger api

by tom.baeyens＠jboss.com

jboss remoting seems a good candidate to make the service facade for the debugger api available. i think we would have to include something like the following in the jbpm-code on potential breakpoints: if (executionContext.isInDebuggerMode()) { | DebuggerExecutionContext dec = (DebuggerExecutionContext) executionContext; | Breakpoint breakpoint = dec.getBreakpoint("node-enter", dec.getNode()); | if (breakpoint.isActive()) { | breakpoint.suspendExecution(); | } | } View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964912#3964912 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964912

19 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - debugger api

by tom.baeyens＠jboss.com

"Alex" wrote : Providing a debugger API is a compelling task. I thought about it for a while and here are my first ideas. Comments are welcome :) | | Debugging is about setting breakpoints in the process *definition*, intercepting the *execution* and then stepping through the following steps. jBPM already offers a mechanism to observe the execution of a process. I can think of providing debugging facilities by creating a process instance with runtime actions installed at the node-enter event of every activity. I will call them "interceptors". | | There are two execution modes, "continuous" or "step-by-step". In the former, only interceptors marked as "breakpoints" can suspend the process execution. In the latter, all interceptors can suspend execution. | | Communication between the BPEL runtime and the debugger occurs through some remoting technology. EJBs are an option, but web services seem more appropriate since BPEL is about web services. | | The exposed operations are: | | setBreakpoint(processName: QName, activityName: String) | ---- | Mark the interceptor at the entrance of the specified activity, which belongs to the specified process, as a breakpoint. | | debug(processName: QName) : ProcessInstanceHandle | --- | Create an instance of the specified process for debugging purposes. Returns a handle to the newly created instance. | | getBranches(instanceHandle: ProcessInstanceHandle) : List | --- | Retrieves the execution branches of the specified process instance. | | stepInto(branchHandle: ProcessBranchHandle) | --- | Executes the specified branch up to the next activity. If the branch currently points to a scope, execution will proceed up to the activity nested within the scope. | | stepOver(branchHandle: ProcessBranchHandle) | --- | Executes the specified branch up to the next activity. If the branch currently points to a scope, execution will proceed up to the activity that follows the scope. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964910#3964910 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964910

19 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Bean instantiate order with contextual injection

by alesj

If bean that has a 'contextual injection' is defined before the actual injectee, deployment fails. Is there a way to avoid this. Or is this expected behaviour? | | <?xml version="1.0" encoding="UTF-8"?> | | <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | xsi:schemaLocation="urn:jboss:bean-deployer bean-deployer_1_0.xsd" | xmlns="urn:jboss:bean-deployer"> | | <bean name="testObject" class="org.jboss.test.kernel.inject.support.AnnotatedTypeStrictSimpleTestObject" /> | | <bean name="injecteeInterface" class="org.jboss.test.kernel.inject.support.DuplicateTester"/> | | </deployment> | | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964908#3964908 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964908

19 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: create start task inconsistency

by tom.baeyens＠jboss.com

That is indeed an inconsistency which is not easy to solve in the current architecture. The idea is that in jbpm 4, the architecture will change in a way that makes it easier to fix this. Now modules are pluggable. The idea is that you can just plug in or rip out the task management module from a jbpm deployment. That is why the plain process instantiation code cannot have a direct reference to the task managment module to see if there needs a task to be created. If we want to fix this in the current architecture, we would have to expand the current event mechanism to span multiple modules. Now, events are generated in the graph and propagate to the process instance. To accomodate auto task instance creation, we would have to dispatch this event over the module instances once it arrives at the process instance level. Also we should dispatch it over the process definition and all module definitions. This cumborsome and difficult eventing mechanism is one of the reasons why we want to go forward with a different architecture. Modules will not be pluggable in the way they are now. A ProcessInstance will contain the plain graph execution runtime information (as now) but it will NOT contain any module instances. Instead, to add new module instances, inheritence should be used. That way, we will create a JpdlProcessInstance that contains the jPDL modules in the object model. This will remove the module instance indirection and reduce the navigation in the database, thereby significantly improve performance as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964907#3964907 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964907

19 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - create start task inconsistency

by tom.baeyens＠jboss.com

"Jeff" wrote : | | Start-state taskInstances are not created when the | | start-state is entered. | | | | Instead, | | | | TaskInstance taskInstance = | | taskMgmtInstance.createStartTaskInstance(); | | | | must be performed by the client (the jBPM web app does this). | | | | This seems to be inconsistent, in that task-nodes create | | taskInstances if a task is specified in the task-node | | definition (and create-task is not set to false). Also | | problematic for a Seam application, in that there is not easy | | way to tell Seam that this process definition has start tasks | | and must be handled differently. | | | | However it is not clear how to fix this. Start-nodes are not | | "entered" or "executed" like other nodes, so there is no good | | place to hang the invocation to | | taskMgmtInstance.createStartTaskInstance. | | | | Thoughts? | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964905#3964905 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964905

19 years, 7 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 August 2006