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

[Design of JBoss ESB] - Exposing JBossWS Webservice Endpoints...

by tfennelly

OK, I eventually got the 4.2 codebase updated to use the JBossWS 2.0.0 codebase. This required changes to the JBossWS 2.0.x codebase, as well as to the ESB. The main changes of note are: 1) All the SOAP/Webservice components are now out of the listeners module and out in their own "soap" service (in the services dir). 2) The JBossWSAdapter now supports configuration with "JAXB Introductions" for interfaces that are not JAXB annotated. 3) The webservice_bpel quickstart is back in and working now (using JAXB introductions). JAXB Introductions Because JBossWS 2.x is now using JAXB to marshal and unmarshal SOAP message payloads. JAXB requires the Java bindings to be annotated. This causes an issue on the ESB where we want to expose existing interfaces as webservices, where those interfaces are not already JAXB annotated. The solution we have is to allow specification of the annotations in XML. Yep, sounds odd, since one of the main reasons for annotations is to get rid of XML. The XML looks like this: | <?xml version = "1.0" encoding = "UTF-8"?> | | <jaxb-intros xmlns="http://jbossesb.jboss.com/xsd/jaxb-intros"> | |  | |  | <class-intro-config name="com.activebpel.ordermanagement.CustomerOrder"> | <method-intro-config name="get.*"> | <XmlElementIntro namespace="http://org.jboss.esb/quickstarts/bpel/ABI_OrderManager" /> | </method-intro-config> | | </class-intro-config> | |  | <class-intro-config name="com.activebpel.ordermanagement.*"> | <method-intro-config name="get.*"> | <XmlElementIntro namespace="http://ordermanagement.activebpel.com/jaws" /> | </method-intro-config> | </class-intro-config> | | </jaxb-intros> | Basically the configuration allows you to specify 3 of the JAXB annotations (@XmlType, @XmlElement and @XmlAttribute) in XML and target them at specific classes, methods and fields. If you look at the definitions for these annotations and compare them with their equivalent XML representation (XmlTypeIntro etc. - example above), you'll see that they match up exactly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054878#4054878 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054878

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Refactoring access to JBPM database

by rjoachim

Well, that's how things work for about a year now and as it seams you don't like a plugable persistence architectur for JBPM, we'll continue with that workaround. Having said that I personally do not like it with regard to project dependencies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054874#4054874 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054874

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Performance problem in VFS

by david.lloyd＠jboss.com

I don't have commit access. But someone who does can merge this patch: | Index: src/main/java/org/jboss/virtual/plugins/context/AbstractVirtualFileHandler.java | =================================================================== | --- src/main/java/org/jboss/virtual/plugins/context/AbstractVirtualFileHandler.java | +++ src/main/java/org/jboss/virtual/plugins/context/AbstractVirtualFileHandler.java | @@ -53,7 +53,7 @@ | public abstract class AbstractVirtualFileHandler implements VirtualFileHandler | { | /** The log */ | - protected Logger log = Logger.getLogger(getClass()); | + protected static final Logger log = Logger.getLogger(AbstractVirtualFileHandler.class); | /** serialVersionUID */ | private static final long serialVersionUID = 1L; | /** The class serial fields */ | @@ -397,7 +397,5 @@ | this.context = factory.getVFS(rootURI); | this.references = new AtomicInteger(0); | this.vfsUrl = (URL)fields.get("vfsUrl", null); | - // Restore the log | - log = Logger.getLogger(getClass()); | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054841#4054841 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054841

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Performance problem in VFS

by scott.stark＠jboss.org

Just make it static. If subclasses need a different logger name they can add their own static instance as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054834#4054834 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054834

18 years, 9 months

1
0
0 / 0

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

by manik.surtani＠jboss.com

I like the varargs approach, except that it uses varargs to make a param optional (1 instance or none) rather than several instances, which is what varargs were desigend for (and hence IDEs representing them as such). A *bit* hacky, IMO. The other approach is to allow people to pass in many Options, like Jason mentioned, such as node.get(key, Option.FORCE_WRITE_LOCK, Option.FAIL_SILENTLY) but this means we'd need to aggregate the options passed in into a single one - not hard to do, just annoying and defeats the purpose of an Option class. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054831#4054831 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054831

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JORAM-tests.jar is missing test.properties

by clebert.suconic＠jboss.com

Maven is not that hard... I could fix it myself. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054826#4054826 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054826

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: Need to make enhacements to CacheListener API

by manik.surtani＠jboss.com

Ok, so now we're at CR2. Not the time to be changing APIs, but I understand that if we need it we need it. The callbacks in consideration are block/unblock/startTx/endTx, right? I like Jason's approach to using annotations rather than the interface methods - makes things easier for people who don't want to implement everything. What do people think? Can/should we: 1) Live with the current API 2) Add to the existing interface 3) Switch to an annotation based approach 4) Do both 2 and 3, providing users with both ways of implementing listeners? I think if we can live with (1) I suggest we do that. Failing that, I'd go with (3), since we'd be breaking compat with CR2 anyway. Then (2) and finally (4) which I think doesn't add much value. I'd like to do this for CR3, and will hold back CR3 until we have a clear decision on this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054818#4054818 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054818

18 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - Setting the properties on the JAXBContext

by tfennelly

Hi. I need to be able to set the properties on the JAXBContext instances produced by the JAXBContextCache. See JAXBContext.newInstance javadoc. I need to be able to set the properties before making a call to RequestHandler.handleRequest and the JAXBContextCache needs to be able to access that properties list and use it to create the JAXBContext instance. What would be the best way of making these properties available to JAXBContextCache? I've been working off the 2.0 branch. I have this working at the moment simply by setting and getting the properties on a ThreadLocal. I was hoping there'd be a nicer way e.g. by attaching it to the InvocationContext perhaps, but I can't seem locate it in the JAXBContextCache e.g. through the current CommonMessageContext on the executing thread. Any ideas? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054809#4054809 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054809

18 years, 9 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Don; t use JIRA as a discussion forum!

by adrian＠jboss.org

JIRA is not for discussion it is the release notes. If you want to discuss issue raise forum threads here. e.g. This garbage: http://jira.jboss.com/jira/browse/JBAS-4481 which should really have been raised as [urlhttp://jira.jboss.com/jira/browse/JBAS-4487[/url] once the problem is understood. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054807#4054807 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054807

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Problem deleting process instances

by david.lloyd＠jboss.com

There seems to be some problem deleting process instances. I am able to delete definitions (which then subsequently delete all the instances), but deleting a process instance gives me: | 2007-06-15 10:00:18,428 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close PreparedStatement (open PreparedStatements: 1, globally: 1) | 2007-06-15 10:00:18,547 DEBUG [org.hibernate.util.JDBCExceptionReporter] could not insert: [org.jbpm.graph.exe.ProcessInstance] [insert into JBPM_PROCESSINSTANCE (ID_, VERSION_, KEY_, START_, END_, ISSUSPENDED_, PROCESSDEFINITION_, ROOTTOKEN_, SUPERPROCESSTOKEN_) values (null, ?, ?, ?, ?, ?, ?, ?, ?)] | java.sql.SQLException: Integrity constraint violation - no parent FK_PROCIN_ROOTTKN table: JBPM_TOKEN in statement [insert into JBPM_PROCESSINSTANCE (ID_, VERSION_, KEY_, START_, END_, ISSUSPENDED_, PROCESSDEFINITION_, ROOTTOKEN_, SUPERPROCESSTOKEN_) values (null, ?, ?, ?, ?, ?, ?, ?, ?)] | It is trying to insert the process instance again during session flush for some reason - but only when I just delete process instances (not definitions). Anyone else run across this? I think it's a bug, I just can't figure out where it is... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4054802#4054802 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4054802

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