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

[Design of JBoss Web Services] - Re: JBWS-1079 - Incorrect WSDL to Java mapping for anonymous

by jason.greene＠jboss.com

We don't have to follow this, and I don't see why it's necessary. JSR-109 redefined the mapping of wsdl to java, and as long as the mapping file is accurate, it doesnt matter what we call the classes. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978590#3978590 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978590

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - JBWS-1093 - normal servlets the web.xml is modified as if th

by darran.lofthouse＠jboss.com

Originally before the support for Tomcat was added to JBossWS the process of modifying the web.xml was implemented to only modify the servlet entries in the web.xml if the servlet was actually a web service. For JSR-109 deployments web services were identified by the presence of the 'servlet-link' in the webservices.xml, for JSR-181 deployments this was identified by checking if the class has the @WebService annotation. I believe this is still the correct mechanism to identify if the servlet is supposed to be exposed as a web service. For deployments deployed to JBoss from the UnifiedMetaData we can get the list of all of the servlet-links so this could be passed into the 'rewriteWebXML' method to be used to identify which servlets need to be converted. For Tomcat deployments we do not have this information available at the moment. For JSR-109 deployments I think we just need to parse the webservices.xml to get the list of servlet-links. For JSR-181 deployments we are going to need a classloader to load the servlet classes to check if they have the @WebService annotation. Because this is not always called from within the container we are going to need to create a classloader so that we can load the classes in the war, I think we should create a URLClassLoader so we can add all of the jars in the war and the classes folder in the war. The parent of the URLClassloader should be set to the current classloader at the time it is created. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978572#3978572 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978572

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Proposed JBESB Configuration File Schema (JBESB-119)

by mark.little＠jboss.com

Dave, it sounds like this may be more invasive than originally thought. I suggest a two pronged approach. Let's push the replacement back to after the RC. In the meantime, let's look at putting schemas in place for the configuration files that are already there. Arvinder added a validation tool so we should be able to leverage that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978569#3978569 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978569

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Proposed JBESB Configuration File Schema (JBESB-119)

by tfennelly

"daniel.brum(a)jboss.com" wrote : The TB is going to be re-written as part of my tasks for the GA, so you can remove that from your list. Can it rally be removed?? Will there be a period of time where there is no TB? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978567#3978567 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978567

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Proposed JBESB Configuration File Schema (JBESB-119)

by daniel.brum＠jboss.com

The TB is going to be re-written as part of my tasks for the GA, so you can remove that from your list. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978564#3978564 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978564

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Proposed JBESB Configuration File Schema (JBESB-119)

by tfennelly

"mark.little(a)jboss.com" wrote : Stepping back a moment: what's the estimate of time and effort to change the current configuration approach used by GpListener and friends? I'd guess this is what we're talking about: 1. Change GpListener to get PM to read load the config (instead of DomElement) 2. Change all code in GpListener that access GpListener config params + Listener wiring config 3. Change all Listeners that access config params through DomElement 4. Change the ActionDefinition code to access ActionProcessor wiring config info through 5. Changing all the unit and QA tests 6. Changing the Trailblazer Hmmm, I wouldn't be surprised if you had little/no change left out of 7/8 days to be honest. I suppose one could bull into it and get it done quicker, but I'd bet they and others would be dealing with that for weeks after. "mark.little(a)jboss.com" wrote : Time is of the essence here, so something very invasive may not be the best approach until after the RC. +1 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978562#3978562 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978562

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Proposed JBESB Configuration File Schema (JBESB-119)

by mark.little＠jboss.com

Stepping back a moment: what's the estimate of time and effort to change the current configuration approach used by GpListener and friends? Time is of the essence here, so something very invasive may not be the best approach until after the RC. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978560#3978560 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978560

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Documenting Limitations of FileCacheLoader

by galder.zamarreno＠jboss.com

+1 I think it should go on documentation as this information is crucial for the customer to be able to make the decision on which CL to use and be aware of the limitations. Looking back on people's past experience, I think FLC does not perform well when handling big trees. Also, The use of a FileCacheLoader over a shared filesystem by NFS is bad; concurrent access to the file cannot be prevented, therefore you are likely to experience inconsistencies caused by concurrent updates to the same file. Even if I added file locks, some NFS implementations might even ignore the lock requests altogether... ( thanks Bela :-) ) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978545#3978545 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978545

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - JBWS-1133 - Exploded JSR-181 POJO Deployment Fails Redeploym

by darran.lofthouse＠jboss.com

For users deploying a JSR-181 POJO deployment with an exploded WAR subsequent deployments fail as the web.xml is modified with the JBossWS servlet name. On the next deployment it is the JBossWS servlet that is checked for annotations not the endpoint class itself, this means the web service is not detected. The only option the user has is to manually put the original web.xml back in place for each deployment / server restart. A second minor problem is that users deploying JSR-109 POJO endpoints with an exploded war may not want their web.xml modified by JBoss, however their web service is still correctly deployed for subsequent deployments. So far I can see the following options: - 1 - Modify org.jboss.metadata.WebMetaData so that it also reads the init-params from the web.xml, if the servlet-class is an implementation of StandardEndpointServlet then we can lookup the 'ServiceEndpointImpl' parameter and test that instead. 2 - Instead of modifying the web.xml deployment descriptor create a new file to use in place of the web.xml descriptor, this means we can write the changes to the new file without affecting the original file. It is not currently exposed as an attribute of the MBean but the StandardContext class within Tomcat does have an attribute 'altDDName', this attribute can be set to override the name of the deployment descriptor to use so an alternative can be specified. 3 - JBossWS in addition to using the WebMetaData can also parse the web.xml to retrieve the parameters so as for 1 if the JBossWS servlet is found the 'ServiceEndpointImpl' parameter can be used to identify the correct class to check for annotations. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978538#3978538 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978538

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Documenting Limitations of FileCacheLoader

by bstansberry＠jboss.com

Discussion thread for http://jira.jboss.com/jira/browse/JBCACHE-807 I'll do this, but would like input from others on the specific issues with FCL, and in what, if any, use cases it's production use is acceptable. My understanding of the problem with FCL is that the filesystem is not a transactional resource and FCL only makes a small attempt to deal with this (by writing transaction-scoped changes during the commit phase rather than prepare.) This would be an issue if there is some problem writing the changes. It also basically means that only READ_COMMITTED semantics are possible at the cache loader level; enforcing other semantics requires interaction with the cache's node locking (e.g if a node is read from the filesystem in a tx, an RL is held on the resulting cache load, preventing a write from another thread, hence REPEATABLE_READ.) A potential added problem could be related to locking if the cache is configured with isolation level NONE such that multiple threads could simultaneously get a WL on a node and therefore simultaneously write to the same file. Re: uses cases, these limitations are mitigated somewhat if the use case is one where only a single thread should be accessing a given Fqn at any time. For example, possibly session management with sticky sessions. But, consideration needs to be given to factors like any background thread doing eviction. Comments? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978537#3978537 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978537

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 October 2006