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

[Design the new POJO MicroContainer] - Re: VFS3 - missing features and other issues

by david.lloyd＠jboss.com

"alesj" wrote : | My initial port of CL to VFS3 shows missing API: | * http://anonsvn.jboss.org/repos/jbossas/projects/vfs/trunk/src/main/java/o... | * http://anonsvn.jboss.org/repos/jbossas/projects/vfs/trunk/src/main/java/o... | AssembledDirectory shouldn't be needed anymore with the new design (there is only one view of the VFS and that's the fully assembled view). MemoryFileFactory should be replaced with an alternative API... right now it all needs to be explicit (make a temp dir, mount the temp dir in the real VFS, and use getPhysicalFile() to make modifications). I think a static method might be a good idea to do this automatically though. Also the temp file API is bad and needs to be redone. I'll do so next week. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245865#4245865 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245865

16 years, 8 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: beanifying the config

by mark.little＠jboss.com

Sounds like a plan to me. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245853#4245853 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245853

16 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-7032 or ClassLoader::getResources

by stan.silvert＠jboss.com

So how does the resource become available to getResources(resourceName)? In the case of Seam/Webbeans faces-config.xml, this is added to the classpath by a deployer, right? Can't the deployer make the resource available to the web classloader as if it were packaged with the WAR? That would fix the problem no matter how isolation is set. Stan View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245840#4245840 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245840

16 years, 8 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: cannot startProfiler 2.0

by jesper.pedersen

did you try nad go through Chapter 3, 4 and 5 in the user guide in 2.0.0.Beta5 ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245839#4245839 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245839

16 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: New console snapshot published, Task Forms included

by SNy

OK, while the dynamic approach ain't working, I'll workaround by hardcoding the template options (it's a mockup, anyway, so the main aim is to get it working ASAP). As far as suggesting a solution, I guess it depends on wether or not the outcome (as in: result of the action) is actually useful in subsequent process steps. If not, it probably should not be introduced into the process at all. I don't have sufficient insight into the ways of jBPM yet and therefore don't know about side-effects. Another idea would be to have the default context stuff that you put into the form as an independent element/namespace 'ctx' or somesuch, containing everything that would go there (it would be nice, BTW, to have a list of the items one can use, I looked in vain for the activity name). 'ctx' should then be regarded as reserved in some way and not be taken from the process. Or, maybe it would be even better to encapsulate the process variables in an element/namespace of their own, maybe named 'process'? Just my 2 cent, regards, Marko View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245829#4245829 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245829

16 years, 8 months

1
0
0 / 0

[Design of JBoss Transaction Services] - beanifying the config

by jhalliday

In an effort to better accommodate the assorted bean centric configuration and dependency wiring frameworks (e.g. Spring, MC) I'm considering further changes to the way TS internals are configured. Currently we have a property management system based on a per module Environment class (a set of named constant Strings), paired with a per module PropertyManager (which is basically a java.util.Properties). The normal usage idiom for retrieving config is something like String theValue = mymodulePropertyManager.getPropertyManager().getProperty(mymodule.Environment.SOME_KEY); The drawbacks of this are a) it's not type safe - theValue may need munging to a particular type, a somewhat laborious process that's repeated all over the codebase and b) the PropertyManager does not know about default values - applying one is up to the consuming code, which means they are spread all over the place as I discovered whilst trying to update the manuals. What I'd like to do is introduce a per-module EnvironmentBean, which will simply have typesafe getters and setters for any property currently defined in the corresponding Environment class. A singleton instance of this will be created and populated by walking the properties file and calling setters accordingly. Anything not set will have a default value declared in the EnvironmentBean, making it easy to find these. Injection frameworks can retrieve this singleton and apply their own config by making additional setter calls. Usage will therefore become of the form MyType theValue = mymodulePropertyManager.getEnvironmentBean().getMyValue(); and the type conversion and default handling code will vanish from the point of consumption. This will also reduce the desire to do this property retrieval in static blocks, as there will no longer be any significant hassle or performance overhead to retrieving it from the manager on each use. However, actually relocating the retrieval code will need careful thought - in some cases all hell will break loose if a value is changed whilst the system is running. Maybe the javabeans validation/veto mechanism or similar can eventually be used to disallow changes when the system is in certain states. Meanwhile we are no worse off than currently, as System.setProperty carries equivalent risks at present. Thoughts? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245824#4245824 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245824

16 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: MessagingXAResourceRecovery configuration

by jmesnil

I have implemented option #1. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245812#4245812 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245812

16 years, 8 months

1
0
0 / 0

[Design of JBoss ESB] - Re: SOAPProxy Enhancements

by Kevin.Conner＠jboss.com

"dward" wrote : "ammppp" wrote : One customer requirement we've had related to this is to be able to dynamically provide the SoapProxy endpoint. | | Kev and I discussed this briefly this morning. It's not on my plate just yet. ;) If these are hard customer requirements then they must come through PM etc so that they can be tracked and prioritised appropriately. At the moment we are trying to nail down some requirements for accessing the endpoint through UDDI, but something like this may also be added. Having said that there are no guarantees that any of this will make it into the next release as it depends on the rest of the workload. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245763#4245763 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245763

16 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: New console snapshot published, Task Forms included

by heiko.braun＠jboss.com

The problem is rendering of a form in a subsequent step. In that case "outcome" exists as a process variable, and will be injected into the freemarker rendering context and thus freemarker throws a parsing error. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245690#4245690 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245690

16 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: New console snapshot published, Task Forms included

by kukeltje

That it triggered the execution is indeed obvious, but I just figured that if you did not use it as a process variable (in any form), you should be safe. But from your statement I get that it does turn into a process variable automagically. Ok, never would have known that without analysing the source. Thanks for letting me know. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245686#4245686 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245686

16 years, 8 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 July 2009