June 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Build System] - Re: Release of jboss-retro

by jason.greene＠jboss.com

Another idea would be to have the ability to generate a runtime specific to a package namespace / project namespace as part of the retroing process. So, for example, if you retro'd org.jboss.widget.* you would get a runtime jar that has classes org.jboss.widget.jbossretro.rt.* The drawback would be increased sized due to everyone having their own runtime jar, but it isn't that big, and you never have to worry about dependencies, and QA doesn't have to retest yet another combination. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054136#4054136 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054136

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Listener Notifications to happen asyncronously?

by vincent.marquez

regarding http://jira.jboss.com/jira/browse/JBCACHE-1107, will Notification calls happen asyncronously? This concerns me, with the way it was before, you could act upon a new entry in the cache before a 'user' had a chance to interact with it, while now its possible it won't happen in that order. One example I could think of off the top of my head is applying an aspect to anything pulled from the cache. Is performance the primary reason for the scheduled change? If I'm misinterpretting the issue, forgive me, and always, thanks for you time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054129#4054129 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054129

18 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Release of jboss-retro

by david.lloyd＠jboss.com

"pgier" wrote : (...)The problem is that in the new version of jboss retro, some of the classes have been moved to new packages. So code that was retroed with the previous version of jboss-retro will not work with the new runtime.(...) | | So some options are: | | 1. Never make changes to runtime class names or method signatures. | (...) | 2. Change class/package/method names for major versions, and keep a branch for updates to older versions. | (...) | 3. After moving a class, use inheritance to keep a place holder for the old runtime class. | What about simply saying that you can't mix versions of retro'd code? If they ran it once, they can do it again... I guess this means I'm in favor of option #2. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054128#4054128 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054128

18 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Release of jboss-retro

by pgier

Kabir brought up the issue of backwards compatibility with the previous versions of retro, so I'm putting off the release until we figure out a good plan. The problem is that in the new version of jboss retro, some of the classes have been moved to new packages. So code that was retroed with the previous version of jboss-retro will not work with the new runtime. This means that if aop is retroed with the new version it depends on the new runtime, and if the app server is retroed with the old version, it will depend on the old runtime. So some options are: 1. Never make changes to runtime class names or method signatures. Pro: This will allow backwards compatibility in most cases. Con: Not much flexibility for refactoring, we will probably have to include some automated way to run tests that are retroed with the old version running on the runtime of the new version. 2. Change class/package/method names for major versions, and keep a branch for updates to older versions. In this case we will keep a branch to add new features to an old version but keep a compatible runtime. Major versions would be allowed to break compatibility. Pro: Allows refactoring Con: Would have to maintain multiple branches. 3. After moving a class, use inheritance to keep a place holder for the old runtime class. This would mean that after a class is moved, a new subclass of the new class is created in the old location. Pro: Allows refactoring and backwards compatibility Con: Causes a lot of extra placeholder classes hanging around. Maybe the best option is to stick with option 1, until we are able to have multiple retro-runtimes loaded at once (osgi classloader). But I would appreciate any feedback on this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054126#4054126 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054126

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: process patch files

by brittm

anonymous wrote : And you want to update complex processes with patches? Think that is going to work? We already do it (successfully) by directly manipulating the database--sometimes through screens developed for that pupose. (Unfortunately, the 10 or so departments that we serve can't seem to come up with all their real requirements until they start using the system in production. And I suppose we have had one or two *ahem* mistakes on our part.) anonymous wrote : What's easier with patching? 1) With patching, I don't need to deploy configuration and code that I'm not changing. The larger and more complicated an environment becomes, the higher the risk of introducing unintented changes, and hence the more benefits patching provides. 2) If a business looses track of a PAR project for whatever reason (company is acquired, IT is restructured, developers leave, data loss, etc.), and jBPM can't hand back the par file for rebuilding, then patching is the only option other than rewriting the process. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054063#4054063 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054063

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: Classloader leak via CacheImpl.invocationContextContaine

by jason.greene＠jboss.com

The only other options I can think of are: 1) Use varargs put(fqn, key, value, Option...). The problem with this approach is that eclipse treats varags like an array when doing tab completion, so you have to know that you dont need the parameter. 2) Break the API for each element into 2 interfaces. Then add a getAdvanced() or something to return the advanced versions of the methods. This of course only reduces the methods in the simple case for the user. The implementation still has to implement both methods. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054060#4054060 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054060

18 years, 9 months

1
0
0 / 0

[QA of JBoss Portal] - Re: URLNavigator Tests

by julien＠jboss.com

the sequence of generated events that is expected by the tests has to take in account now the presence of "/" entry. it looks normal to me. I think you can go ahead and commit your changes View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054056#4054056 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054056

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: console security

by david.lloyd＠jboss.com

"kukeltje" wrote : me curious to... was just trying the latest console out and have some findings... not sure whether I should report them or not since I do not know if work is still on the todo list and do not want to polute the jira. | | So (O/T) things I notice are: | - tasks can be 'ended' via a normal transition without ever being started, hence no start date in the task (related to the examine thing below) | - the moment the comment appears is confusing.... should maybe be preceded by a popup like 'you just finished this task, do you want to add a comment to it (yes/no) | - the 'examine' is kind of strange.. examine to me is not being able to work on it... (read only) | - Can I start a dutch translation? | Yes, this is an admin console so you can do pretty much anything allowed by the API, including things that are probably not a good idea. Use the security configuration in access.properties to limit access to different functions. The comments screen has a kind of ugly layout, but functionally I think it makes sense. Patches welcome to make it look nicer. :-) The task screens are not intended so much for people to be able to run their day-to-day tasks, but rather so that administrators can see what the status of things are, and "take things over" if needed. As for a dutch translation - please do! You can point out all the faults in my L10n efforts. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054052#4054052 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054052

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Thinking about transition attrs

by brittm

Namespaces seems like a good idea *if* jBPM could throw that part of the configuration into 'external config' tables with a foreign key to the jpdl parent element. I wouldn't care if the configuration were simply stored as a string--at least it would be trivial to retrieve in relation to the appropriate jpdl element. We're already doing this kind of thing with ActionHandler configuration. Of course, we could do the same thing with a generic "meta" tag on the key jpdl elements. One advantage to this approach could be that if we see people using this functionality to carry the same types of configuration over and over, then that usage could be a candidate for standardizing in the jpdl. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054049#4054049 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054049

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jbpm4jsf java 5 dependency

by kukeltje

With regard to making it easy for the user to deploy correct versions. I'd like to propose the ability to configure what database dialect should be used when building the webapps/ear. So it is really build and run... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054044#4054044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054044

18 years, 9 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 June 2007