September 2007 - jboss-dev-forums

[Design the new POJO MicroContainer] - Re: Annotation processing

by alesj

"adrian(a)jboss.org" wrote : | It's only real use at the moment is in AOP to find out if there are instance annotations. | That processing is wrong anyway. There should be a | MetaData.hasInstanceMetaData() instead. | What's the difference between local and non-local retrievers (from MetaDataContext): | /** | * Get the retrievals | * | * @return the retrievals | */ | List<MetaDataRetrieval> getRetrievals(); | | /** | * Get the local retrievals | * | * @return the local retrievals | */ | List<MetaDataRetrieval> getLocalRetrievals(); | I guess this needs removal as well (from KernelControllerContextAction): | if (joinpoint instanceof KernelControllerContextAware) | ((KernelControllerContextAware) joinpoint).setKernelControllerContext(context); | ... | if (joinpoint instanceof KernelControllerContextAware) | ((KernelControllerContextAware) joinpoint).unsetKernelControllerContext(null); | Since all information for AOPConstructorJoinpoint should then be in MetaData instance taken from the stack? Any quick tips on how MetaData.hasInstanceMetaData() should look like? Should it still use MetaDataContext as current impl in AOPConstructorJoinpoint does? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080773#4080773 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080773

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mc release prep

by scott.stark＠jboss.org

I'll be looking to do the mc release tomorrow after validating the ManagedOperation behavior. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080709#4080709 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080709

17 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Feature Request - global lists API

by camunda

In my opinion the best place for your own java code is then a own Command (Command Pattern is introduced in jbpm 3.2.x), for example there exists a org.jbpm.command.GetTaskListCommand You can now extend this one to implement your own behaviour and create your own hibernate query. For the Command pattern you just have to implement a method: public Object execute(JbpmContext jbpmContext) throws Exception View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080706#4080706 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080706

17 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Feature Request - global lists API

by simonbaker

Isn't it quite hard to maintain a customized jBPM as new versions come out? You'd have to keep track of every change or addition to the code, and make them all over again -- or is there a better practice? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080690#4080690 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080690

17 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Feature Request - global lists API

by jeffdelong

Yes, the best way is to create a new hibernate query as you suggest. You can us the existing ones as a starting point, adding, or in your example, deleting where clause parameters. This is a great use of the underlying architecture - using hibernate queries in this fashion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080684#4080684 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080684

17 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Feature Request - global lists API

by simonbaker

OK, but although the db model is open, developers would prefer to have an API that is database neutral and basically hides the persistance layer for ease of use. For small companies like ours, it is expensive to maintain code at the database level. And in general, when a new version of jBPM comes out, custom code for the old version can be a nightmare to integrate in the latest. I agree you don't want to abuse the "getAllTaskInstances()" type of call for performance reasons, but I have worse situation now. To get all the task instances, I'll have to make a list of all actor ids and, I guess, call "TaskManagementSession.findTaskInstances(List actorIds) which is I suspect a fairly inefficient query. However, I know I'm new at jBPM so I'd like to learn more about extending it. For example, if I wanted a "getAllTaskInstances()" method, would the best approach be to add my query to the "hibernate.queries.hbm.xml" file (does that mean learning Hibernate generic SQL?) and coding a new method, say "TaskManagementSession.getAllTaskInstances()", following the example of the similar methods? Or is there a better place to hang custom code? I realize those last questions belong in the user forum. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080681#4080681 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080681

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mc eclipse project has ant 1.7.0 build path problems

by scott.stark＠jboss.org

The mvn compile is working, and if I look at the ant being resolved, its using the ant-1.6.5.jar from my local repo. The ant jars are not required for eclipse as I can remove these and run the tests. What needs these in the eclipse classpath? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080677#4080677 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080677

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - mc eclipse project has ant 1.7.0 build path problems

by scott.stark＠jboss.org

Today when I opened the mc projects in eclipse there are several path problems relating to ant 1.7 paths: Severity and Description Path Resource Location Creation Time Id Project jboss-aop-mc-int is missing required library: '/home/svn/repository.jboss.com/maven2/org/apache/ant/ant-junit/1.7.0/ant-junit-1.7.0.jar' jboss-aop-mc-int Build path 1188860995509 69217 I don't see this in the jboss repo. There are also ant 1.6.5 refs that use a different group id, and this is in the repo: I don't understand why I did not see this before as the classpath change has been in there a while (Jul 12). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080675#4080675 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080675

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MC meets Drools - new Reliance module

by alesj

"alesj" wrote : | I'll wait with commiting this stuff after Scott releases MC beta4. | I've commited the code, since it doesn't clash with any previous work. And also being an appropriate time, since all the tests are working again. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080667#4080667 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080667

17 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: directory/package structure

by kukeltje

Yep View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080661#4080661 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080661

17 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2007