February 2009 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: JBREFLECT-50, determining need for setAccessible bug

by scott.stark＠jboss.org

I think the correct solution is to add a new BeanAccessMode.INTERFACES enum value that indicates that only methods matching interfaces the bean implements will be incorporated into the BeanInfo result. This should then be the default mode for non-public classes? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210779#4210779 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210779

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Kernel beans initialization in JBossAS

by alesj

WRT: - http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210683#4210683 - https://jira.jboss.org/jira/browse/JBAS-6514 I'll create new kernel.xml file for bootstrap.xml. Or should I stick it into some existing boot file? But imo this is more "natural", as is similar to what we have with vfs, cl, deployers, jmx, ... Hence the MC's Kernel gets its own init file as well. ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210777#4210777 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210777

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Logging integration requirements

by david.lloyd＠jboss.com

I've posted the logging integration requirements in a Wiki article here: https://www.jboss.org/community/docs/DOC-13346. If you have any comments or contributions, post them here or on the article. I'm developing this in earnest so if you have anything to say, say it now. :-) I intend to get this done in time for the first 5.1.0 beta. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210745#4210745 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210745

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: oryx and jbpm

by kukeltje

"eikish" wrote : Hi, I'm that "Eiki" :) | Welcome "eikish" wrote : | Unlike the Orbeon editor ours isn't itself based on xforms just web2.0 magic and right now it's closed source although we are planning to make our platform available for other developers and are open to suggestions ;) | Web 2.0.... That I know.... there I can contribute.... hahaha "eikish" wrote : | The oryx xforms editor is a little strange to me as well as many of the other editors out there. It seems that developers are mostly creating visual XForms syntax editors but not form editors that use XForms underneath if you know what I mean....anyway that's off topic | It's not realy off topic... it makes it easier or more difficult for e.g. others to extend it if they want/need.... see my remark about your version "eikish" wrote : | Looking at the JPDL4 editor (only seen the alpha1) I see jboss is taking the road of integrating the positioning of the elements into the xml instead of the gpd.xml file. This is a smart move in my view and will make it easier to create designers/exporters for jpdl. | @Tom: yeeehaaa.... hahahaha "eikish" wrote : | I think with Oryx this strategy would be best as well but I'm worried about backward compatability. We are using jBPM 3.3 and don't see that v.4 will be out any time soon so I need to make sure we build (or you as well?) a jpdl extension to oryx that will work on jBPM 3.3 as well... | July 1st is the target date "eikish" wrote : | Will JPDL4 work on 3.3? | No Maybe Chiba and your editor should become JBoss projects :-) btw, I just use chiba/xforms for the tasks, not tasklists... tasklists are plain jsf View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210739#4210739 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210739

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - java.util.logging.MemoryHandler

by tom.baeyens＠jboss.com

i'm playing a bit with the java.util.logging.MemoryHandler in test-db and it seems to work nicely. it will store the logs in memory in a circular buffer overwriting the oldest entries first. whenever a log is issued in category severe (==error) then the last 500 log entries are flushed to the console. that way you can have quite detailed logging when something goes wrong and no logging then things go ok. seems to work nice. i'll work with it some more before i roll it out over the full project. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210713#4210713 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210713

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: oryx and jbpm

by eikish

Hi, I'm that "Eiki" :) We are also using Chiba for our display needs (modified a little) but we have already a working but not polished XForms browser based editor we developed in house and we connect that to JBPM. We can for example see all tasks in a process version as xforms and edit them even for running processes (older versions) and add and remove variables (set access (read,write,required)) and easily map them to inputs. This is part of our CeSM platform (Customer eServices Management , a new buzzword you heard it here first :p ) Unlike the Orbeon editor ours isn't itself based on xforms just web2.0 magic and right now it's closed source although we are planning to make our platform available for other developers and are open to suggestions ;) The oryx xforms editor is a little strange to me as well as many of the other editors out there. It seems that developers are mostly creating visual XForms syntax editors but not form editors that use XForms underneath if you know what I mean....anyway that's off topic About Oryx, it's very well made but I agree with kukeltje the built in repository and even openid support is something we probably won't use because we already have our own authentication and repo. Also we want to build a jpdl designer with handy extensions for our custom actionhandlers to make it truly possible for a newbie (non programmer) to design and test a complete process. The requirements in our case in other words are being able to draw and export the xml. But when we have that we will integrate it with our form designer so we can jump right to a task and edit it. Looking at the JPDL4 editor (only seen the alpha1) I see jboss is taking the road of integrating the positioning of the elements into the xml instead of the gpd.xml file. This is a smart move in my view and will make it easier to create designers/exporters for jpdl. I think with Oryx this strategy would be best as well but I'm worried about backward compatability. We are using jBPM 3.3 and don't see that v.4 will be out any time soon so I need to make sure we build (or you as well?) a jpdl extension to oryx that will work on jBPM 3.3 as well... Will JPDL4 work on 3.3? cheers Eirikur Hrafnsson, eiki(a)idega.com Chief Software Engineer Idega Software http://www.idega.com View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210712#4210712 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210712

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Strongly type assignment and pooled tasks

by tom.baeyens＠jboss.com

Johan, good to hear from ya ! as you mention in your point 2) can you give some concrete indication of what different dimensions your sticking into the actorId references ? or in other words: what kind of individual data items do you combine in the assignment String's ? secondly, our current plan is to make the difference between user-references and group-references more specific in the api. also we plan to have generic participations associated to tasks (and swimlanes). so you can associate users and groups as a participant to tasks or swimlanes and specify a participation like e.g. candidate, owner, viewer, client and so on. we have some constants defined, but participation is string based, so you can put your own participation if you like. would that help ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210709#4210709 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210709

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Clustered DeploymentRepository for 5.1

by bstansberry＠jboss.com

Thanks for the link. :) I knew there was a thread about this stuff, but yesterday the forum was taking 2 mins to reply to every click so I just gave up looking and posted. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210707#4210707 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210707

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: Strongly type assignment and pooled tasks

by heiko.braun＠jboss.com

Johan, maybe you should join the recent discussions about the task management impl. for jbpm4. It already addresses some the shortcomings in jbpm3: [url] http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150637 [/url] Your feedback on this would be appreciated. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210684#4210684 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210684

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: task assignee vs owner

by tom.baeyens＠jboss.com

"KrisVerlaenen" wrote : I believe a task component would probably be one of the easiest component to collaborate on (as it can be completely decoupled from the internals of the execution engine). We have expressed our interest in collaboration on this over half a hour ago and I have repeated this numerous times. What disappoints me is that the you guys now apparently decided to start creating something entirely custom without any communication whatsoever. | | Kris i don't see it the same way. we had a task component in jbpm 3 and we are building an improved version for jbpm 4. in the meantime, i saw that you have also build a task component as well. first of all, our time constraints don't allow us to endeavour on a unified task component. it takes *a lot* of time to understand each others goals, implementation, merge and work like that. we simply don't have the time to go through that process at this stage. i assume that you are aware of this as you also point us to your code without working with us on our project. no offence intended, just pinpointing that the hard part is the merging of ideas and requirements into a single unified implementation. also, i don't think it is good to spend energy on building a "unified" task component for 2 engines which should have be one in the first place. we don't have time enough to consider the merge-components strategy. but you are welcome to join our development efforts if you're interested. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210680#4210680 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210680

17 years, 1 month

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 February 2009