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

by kukeltje

with almost required I mean that there is no automagically runtime generated form anymore. Designing a process and running it, requires forms to be generated. Therefor it should not be under the advanced section. Koen probably had to much Dutch beer and sees things that in reality are not there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984476#3984476 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984476

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Task Forms

by tom.baeyens＠jboss.com

"kukeltje" wrote : anonymous wrote : merging the diffs by using markers is a pain. not worthed imo. | | hmm.... what about generating a new form with and then allow the user to use the diff functionality of eclipse? | under assumption that the diff editor is easy to bring up, that would be a very good idea. "kukeltje" wrote : anonymous wrote : the only thing that i think we should make easier is automatic regeneration of forms if form data is changed. | | And the place of the generate forms (it's on the advanced tab but is almost 'required' now) | What do you mean with 'almost required' ? "kukeltje" wrote : anonymous wrote : In that case, regeneration of the form would imply that the user has to enter all the variables again. | | ???? Can't this be automatically populated? (I cannot use the gpd from cvs head now, it's not functional so I cannot test this) We're doing our best to get the next alpha out the door. There you should be able to see the form generation in action. You can already check the Alpha1, but in my case this didn't work (Koen says it works for him:-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984467#3984467 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984467

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Task Forms

by kukeltje

anonymous wrote : merging the diffs by using markers is a pain. not worthed imo. hmm.... what about generating a new form with and then allow the user to use the diff functionality of eclipse? anonymous wrote : I propose that we first implement generation without synchronization and see what kind of feedback we get on that. I agree anonymous wrote : the only thing that i think we should make easier is automatic regeneration of forms if form data is changed. And the place of the generate forms (it's on the advanced tab but is almost 'required' now) anonymous wrote : In that case, regeneration of the form would imply that the user has to enter all the variables again. ???? Can't this be automatically populated? (I cannot use the gpd from cvs head now, it's not functional so I cannot test this) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984465#3984465 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984465

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: ws-eventing: event notification failure

by heiko.braun＠jboss.com

sorry stefano, i missed this one. here are my two cents: a) notification failures: sure, it sound reasonable to track them through the SubscriptionManager. Resending (means queuing) would require additonal constraints (expiration policy, softening, etc). This already sounds like jms integration to me. I was thinking about that in the beginning, if further QoS capabilities can be delegated to an JMS instance. b) clustered environment: this would needs to be elaborated further. Could you provide some diagrams? We could use the WIKI for this... c) Did you take alook at WS-Notifcation? WS-Eventing is kept really simple, WSN adds a lot of concepts. It might be worth comparing these specs before actually modifiying the WS-Eventing codebase. d) If you have fun coding these issues, i have fun helping you out where ever i can. Please contact me directly if you need any additional svn privileges. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984464#3984464 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984464

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Task Forms

by tom.baeyens＠jboss.com

merging the diffs by using markers is a pain. not worthed imo. I propose that we first implement generation without synchronization and see what kind of feedback we get on that. the only thing that i think we should make easier is automatic regeneration of forms if form data is changed. can we (and if so, how) store the form generation data into the processdefinition or gpd xml file. the most frequent use case is a task without a controller, with several data items in the form (directly onto the process variables). In that case, regeneration of the form would imply that the user has to enter all the variables again. This is because we take the variables of the controller as a starting point. But if there is no controller, you have to start entering the form data items from scratch each time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984460#3984460 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984460

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Task Forms

by koen.aers＠jboss.com

Maybe we should take the approach as it is done in the tooling of the Eclipse EMF project. These tools generate Java artifacts that you can customize afterwards. All generated artifacts have a '@generated' annotation and they keep being regenerated (thus erasing possible customizations) unless you remove the '@generated' or replace it by '@generated NOT'. Would this be acceptable? Regards, Koen View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984442#3984442 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984442

19 years, 5 months

1
0
0 / 0

[Design of JMX on JBoss (JBoss/JMX)] - Problem acceding EJB in a enterprise application

by ANDRIA-NTOANINA

I've tried to access my Enterprise bean in an Enterprise application client. Using this code : Context c = new InitialContext(); | return (BeanSessionRemote) c.lookup("java:comp/env/ejb/BeanSessionBean"); but when I run my application I got the next Exception: javax.naming.NamingException: Failed to find j2ee.clientName in jndi env | May anybody help me? Thanks a lot! PS: I'm using NetBeans 5.5 and I write in english very bad View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984427#3984427 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984427

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Possible optimization of CachedSetImpl

by ben.wang＠jboss.com

Well, the cost is more of shifting the current pojo at index (i+1) to (i) with detach and then attach when I do a remove (o) where o resides at index (i). So I am saying we don't have to shift since Set is neither ordered or indexed. BTW, just looking at it again, I don't think add(o) will prevent duplication as key can be different. What do you think? Yeah, the whole suite is functionalPojoCacheTests. It'd certainly be nice to run through it once a while. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984405#3984405 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984405

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Injecting properties in WarDeployer(setters in the base

by scott.stark＠jboss.org

The property setters were working, its just that they were not being propagated to the TomcatDeployment from within the getDeployment callout. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984388#3984388 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984388

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: DeploymentInfo and DeploymentContext information

by scott.stark＠jboss.org

system-jmx contains both the old deployer classes and the new mc based deployers. The tests still need to be updated to the VDF. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984386#3984386 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3984386

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