April 2008 - jboss-dev-forums - Jboss List Archives

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Used of JGroups shared transport in AS 5

by bstansberry＠jboss.com

anonymous wrote : The AS's channel factory bean is already an AS-specific impl of the ChannelFactory interface. I intend to alter the impl of the "createMultiplexerChannel" methods so they analyze the configuration of the specified protocol stack. If it supports a shared transport, I will return a shared transport channel. If not, I will return a MuxChannel+Multiplexer+JChannel. This is a bit hacky, given the name of the method, but I think the benefits are worth it. This has evolved further. The AS ChannelFactory will never return a MuxChannel. If a user invokes one of the createMultiplexerChannel methods and the TP config doesn't include a singleton_name, I'm going to create a singleton name for that channel and inject it into its config, log a WARN and return a shared transport channel. Created name will be "unamed_" + stack_name. http://jira.jboss.com/jira/browse/JBAS-5442 Re: the hackiness of the AS approach given the name of the method, I suppose it's a bit less hacky than I was thinking. A shared transport channel is still a "multiplexer channel". The multiplexing happens in the transport itself, when it chooses what up-protocol to pass an incoming message to. The fact that JG had another impl that involved an implementation detail class called "Multiplexer" doesn't mean the word multiplexer is forever reserved for that particular impl. The AS fix is still hacky though, as the method signatures of the two createMultiplexerChannel methods include other params besides the stack name that are now totally ignored. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144208#4144208 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144208

16 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JBoss SOA Platform

by burrsutter

Send me an email (maybe 2, I get a lot) and we'll try to work this out. Burr View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144207#4144207 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144207

16 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Programmatic policy for jar handling

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | The StructureDeployers are only looking for resources and creating ContextInfo. | The real VFSDeploymentContext is constructed once the structure is determined. | | See VFSStructureBuilder::createChildDeploymentContext() | which is where any additional metadata (e.g. unpack) would actually get used. In principle it could be all implemented in that method. If the ContextInfo says unpack=true we just copy the nested jar to temp and create a VirtualFileContext over it. The issue would be to make sure that the context has the correct parent such that it still has the correct VFS name. This is similar to how to the current (but unused) copy to java.io.tmpdir works so I knows its possible :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144204#4144204 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144204

16 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Programmatic policy for jar handling

by adrian＠jboss.org

"alesj" wrote : | "adrian(a)jboss.org" wrote : | | Other more automatic rules should be in the Structure Deployers. They're the ones that know a context is a war and can decide based on some metadata in the deployment or an external rule that a paricular war or all wars should be unpacked when they are subdeployments. | Then it could be too late. | e.g. a War Structure deployer is already going inside war file, checking for WEB-INF and web.xml, by such caching the handler on its parent. | And we already used what we actually wanted to set - we either created the copy, but the policy would say not to create them, or vice versa. The StructureDeployers are only looking for resources and creating ContextInfo. The real VFSDeployment is constructed once the structure is determined. See VFSStructureBuilder::createChildDeploymentContext() which is where any additional metadata (e.g. unpack) would actually get used. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144202#4144202 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144202

16 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1316 - Add support for a configurable time toleranc

by darran.lofthouse＠jboss.com

Thanks, I have committed the changes. The configuration is documented here: - ttp://jbws.dyndns.org/mediawiki/index.php?title=WS-Security_options#Advan... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144198#4144198 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144198

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: webservices ejb3 api usage

by wolfc

"heiko.braun(a)jboss.com" wrote : To me the order of injection vs. method invocation is an implementation detail of the EJB3 domain. | | If I understand you correctly we speak about dependency injection before the bean becomes method-ready, right? Yes and it's not an EJB 3 problem: "JAX-WS 2.1 5.2.1" wrote : Endpoint implementors MAY use the WebServiceContext facility (see 5.3) to access the message context and other information about the request currently being served. Injection of the WebServiceContext, if requested, MUST happen the first time the endpoint is published. After any injections have been performed and before any requests are dispatched to the implementor, the implementor method which carries a javax.annotation.PostConstruct annotation, if present, MUST be invoked. Such a method MUST satisfy the requirements for lifecycle methods in JSR-250 [31]. You need the intermediate deployer to access any EJB 3 meta data. WebServiceDeployment and WebServiceDeclaration should not be implemented by any runtime container or even exist in the first place. As for the WebServiceContext. The InvocationContextCallback should not exist. You should specify an WebServiceContext injection handler on the injection component which injects a WebServiceContext which delegates to a thread local WebServiceContext. That thread local should be set before the invokeEndPoint. The only problem is that the injection component is in the works and will probably not be integrated with EJB 3 before AS 5.1. So for the moment we could keep the InvocationContextCallback and I'll handle the thread local stuff (as in EAP 4.x). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144193#4144193 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144193

16 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Programmatic policy for jar handling

by alesj

"adrian(a)jboss.org" wrote : | At the vfs level this is either a parameter on the initial url a failing that or a different protocol | type to support the legacy unpacking mechanism and the return of a "jar:" url | from the VirtualFile.toURL(). | | For programmatic deployment its easy to decide what the URL upfront should be. | Is there a better way to do this than this: | URL url = getResource("/vfs/context/" + name); | URI uri = new URI(url.toExternalForm() + "?useCopyJarHandler=true"); | "adrian(a)jboss.org" wrote : | Other more automatic rules should be in the Structure Deployers. They're the ones that know a context is a war and can decide based on some metadata in the deployment or an external rule that a paricular war or all wars should be unpacked when they are subdeployments. Then it could be too late. e.g. a War Structure deployer is already going inside war file, checking for WEB-INF and web.xml, by such caching the handler on its parent. And we already used what we actually wanted to set - we either created the copy, but the policy would say not to create them, or vice versa. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144191#4144191 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144191

16 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Programmatic policy for jar handling

by adrian＠jboss.org

That's very adhoc and hacky and in the wrong place. The VFS doesn't need callbacks based on path names (which aren't even guaranteed) with the real semantics belonging in the VDF. The real issue is how the creator of the deployment controls the VFS url and the behaviour required behind the scenes to handle this problem. At the vfs level this is either a parameter on the initial url a failing that or a different protocol type to support the legacy unpacking mechanism and the return of a "jar:" url from the VirtualFile.toURL(). For programmatic deployment its easy to decide what the URL upfront should be. Other more automatic rules should be in the Structure Deployers. They're the ones that know a context is a war and can decide based on some metadata in the deployment or an external ruile that a paricular war or all wars should be unpacked when they are subdeployments. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144186#4144186 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144186

16 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Programmatic policy for jar handling

by alesj

Regarding yesterday's discussion about breaking existing external frameworks working on top of VFS and no_copy jar handling. One way to change the behavior is by changing URI, to add additional query parameter. But I think we should add better control over this, introducing some sort of policy into VFSContext (or some other top level handle). This is what I have initially in mind: | public interface JarHandlerPolicy | { | /** | * Should we create a copy. | * | * @param context | * @param parent | * @param jarFile | * @param entry | * @param url | * @param entryName | * @return | */ | boolean createCopy(VFSContext context, VirtualFileHandler parent, JarFile jarFile, ZipEntry entry, URL url, String entryName); | } | which would get used at the point where we decide whether we copy the jar or not: | JarHandlerPolicy policy = context.getPolicy(); | if (forceCopy || policy.createCopy(context, parent, getJar(), entry, url, entryName)) | vfh = NestedJarHandler.create(context, parent, getJar(), entry, url, entryName); | else | vfh = new NoCopyNestedJarHandler(context, parent, getJar(), entry, url, entryName); | And for example, very simple war policy would look like | public class WarHandlingPolicy extends AbstractJarHandlingPolicy | { | public boolean internalCreateCopy(VFSContext context, VirtualFileHandler parent, JarFile jarFile, ZipEntry entry, URL url, String entryName) | { | return entryName.contains(".war"); | } | } | | public abstract class AbstractJarHandlingPolicy implements JarHandlerPolicy | { | public boolean createCopy(VFSContext context, VirtualFileHandler parent, JarFile jarFile, ZipEntry entry, URL url, String entryName) | { | return hasCopyOption(context) || internalCreateCopy(context, parent, jarFile, entry, url, entryName); | } | | protected abstract boolean internalCreateCopy(VFSContext context, VirtualFileHandler parent, JarFile jarFile, ZipEntry entry, URL url, String entryName); | | protected boolean hasCopyOption(VFSContext context) | { | Map<String, String> options = context.getOptions(); | return (options != null && options.get(VFSUtils.USE_COPY_QUERY) != null); | } | } | The question is, if we decide to go this way, where do we set this policy? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144184#4144184 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144184

16 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Where to create your tests

by richard.opalka＠jboss.com

This is probably addressing my current work. I'm creating WS-RM tutorial for each stack at the moment. WS-RM is different for each stack, so I decided to put wsrm samples to stack code base instead of framework. These samples will be part of WSRM tutorial. I plan to create cross stack WS-RM test suite too. However it will deal with reflections to be executable cross stacks. I don't want to deal with reflections in WS-RM tutorial and scare some users ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144183#4144183 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144183

16 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2008