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

[Design of POJO Server] - Re: Stable deployment API for tools

by max.andersen＠jboss.com

While we are at it any chance this could be isolated into a jar that could be placed in a 5.0.x AS and have the api work there too ? (just a wish ;) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215477#4215477 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215477

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by stale.pedersen＠jboss.org

while waiting for the classloader changes i wish to push the work ive done to jboss-reflect/trunk. it uses the same classloader strategy thats in trunk now so it wont change anything. ive already created a factory/interface to fetch the classpool which can easily be replaced when kabir is done. ill look over the tests and probably extend a few a bit more, then ill try to write up some docs on the wiki on how it works and hopefully merge next week if noone objects. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215467#4215467 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215467

17 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Re: Management of deployed bundles

by scott.stark＠jboss.org

The wiki page where I describe the management annotations and have examples of various deployments using them is: http://www.jboss.org/community/docs/DOC-11349 How are these mbeans being deployed currently? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215464#4215464 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215464

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Stable deployment API for tools

by alesj

Where in jbossas should I put this interface(s)? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215453#4215453 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215453

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - approach to new forms

by kukeltje

Thanks for the initial discussion. I have a more clear picture now on the position of you guys, but still have a some questions idea's therefor some statements (sometimes a summary of the discussion) on which I hope you can comment. jBPM 3 forms solution is not sufficient for (at least) several reasons (not al mine, sometimes customers, sometimes a console thing) - typing is not taken into account (e.g. no datepicker out of the box) - complex forms not supported (nested elements) - cannot be (easly) used outside of the console The jBPM forms solution also has an advantage: - a simple RAD type demo can be done showing a full process with (simple) forms - forms can be customized afterwards to at least a certain extend Console thing: - look and feel customization is limited (logo, colours, big customer issue, where big mainly refers to customer and not (specifically) the issue) Now the question for me which problems do we want to solve and when. Do we want to go the whole 9,1140 meters in the 1st down ( , is decimal separator :-) ) or do we take it in smaller steps. Statistics show not going al the way has a higher success rate. Now why do I state this. There were 3 approaches to the current console 1) It is the holy grail (nirvana if you are into bhuddism), I want to (ab)use it and extend it as much as possible 2) it's nice for RAD, nothing more and forms can be customized to a certain extend little 3) Not use it only for deployment and overviews. My opinion: 1) People using like this were either crazy (personal opinion), had different experience with other bpms or just had different expectations, or limited knowledge of frameworks 2) Not a bad choice, did that to once or twice 3) Most likely what sensible people did (me to) but there I developed a framework which made it possible to do RAD, just with a custom webapp (combined with custom look and feel) Why would people go for 1? - Out of the box usage - they did/do not have java developers Problems: - no easy access to own datasources etc - repackaging for using own beans etc - you need java delvelopers Why did people go for 3? - They had a different inhouse technology (e.g. struts) - They could not easily re-use the forms solution (including tasklists) or they did and we (ok mainly you JBoss guys) did not know Problems: - you need java developers Now I personally think that the forms solution should eventuallly comprise several things a) Good and stable api for taskmanagement b) Tasklist functionality (not reassignment etc) c) Basic forms functionality (little more complex then there now is), e.g. datepickers, but not repeatable items(complex types) etc d) editor/designer support for c) e) Complex forms functionality f) Designer support for e) g) Reusable components, preferably to a large extend independent of the rest of the ui technology But I'd spread this over 3 iterations (assuming 8 weeks release cycles) and 4.1 being after 4.0.1 1) 4.0.0.GA: a, b, c, d 2) 4.0.1: e, f 3) 4.1: g Now if you look at the amount of work that still needs to be done, not only for the forms, but in general, and at the same time keeping in mind that backwards compatibility for the existing forms should be supporterd (it should shouldn't it?), I'd take the following approach: Whatever forms solution is used, it is not a bad thing to go for handling forms in iframes. This way, it should not be to difficult to leverage the existing forms functionality without the existing console. They could be run in the new console with some slight adaptations in the backend of the formshandling I'd think. At the same time it could be deprected so to make clear it will not supported in 5 anymore. This buys a little more time to get the new forms solution up and running (it does not have to be ready for 4.0.0.GA, only demonstrable (? stupid word)) and in the mean time, announce it, describe it, look at conversion of the existing variable definition to the new one (should not be that difficult). Personally there is only one option for this. XForms since much of it will be in html5/xhtml2, lots of other vendors support it (IBM, Intalio, SAP, Nuxeo, Alfresco, Orbeon To summarize: Advantages of this approach: - backwards compatibility is met - initial improvements are there - time is bought to focus on delivering at july 1st with a quality release - jBPM enhanced forms handling can be announced, technology wise - a conversion of the current variable definition to a new one is possible any comments? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215420#4215420 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215420

17 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Stable deployment API for tools

by jason.greene＠jboss.com

This work is a blocker for 5.1 CR1 [url]https://jira.jboss.org/jira/browse/JBAS-6330[url] View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215406#4215406 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215406

17 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: Smooks & Groovy mask illegal attribute names

by tfennelly

I created the JIRA here MILYN-252. If you need this fix in a hurry, you can easily fix and patch locally. Checkout the v1.1.1 tag from http://svn.codehaus.org/milyn/tags/Smooks_V1.1.1/, go into the scripting cartridge and edit the .ftl template used to generate this code (ScriptedGroovy.ftl). Just remove this variable. Build the scripting cartridge and patch your local ESB. Sorry for the inconvenience. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215388#4215388 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215388

17 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: Smooks & Groovy mask illegal attribute names

by tfennelly

You're totally right... that's a bug. There's no need for that variable at all. The element can be referenced as "element". I'll add a JIRA for this in Smooks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215382#4215382 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215382

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by kabir.khan＠jboss.com

"stale.pedersen(a)jboss.org" wrote : im not sure if kabir will finish this at all anymore and even more if jboss-reflect need it since aop wont be changed to use it anyway. | I think this will need doing, it should be trivial. (The cl stuff StÃ¥le was talking about is http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150699. The ideas I have there so far are crap, I'll think more about these over the weekend and come up with some better suggestions.) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215378#4215378 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215378

17 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Re: JBOSGI-38 and bundle deployment order

by adrian＠jboss.org

"alesj" wrote : "thomas.diesler(a)jboss.com" wrote : If I am in a Deployer already and have a DeploymentUnit is it then somehow possible to set the "required state" ? | | | | | ControllerContext cc = unit.getTopLevel().getAttachment(ControllerContext.class); | | cc.setRequiredState(someState); | | Ugly! :-) If you really want to be able to do this (rather than specifying it at deployment time) then add setRequiredStage(DeploymentStage) to the DeploymentUnit/Context. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215370#4215370 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215370

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