September 2006 - jboss-dev-forums

[Design of JBoss ESB] - Re: Smooks Transformation Integrated

by mark.little＠jboss.com

"tfennelly" wrote : I completed round 1 of integrating Smooks into the ESB. This included modifying the Trailblazer to use the "SmooksTransformer" for one of the transfomrations. | | I've also started and commited a Message Transformation Guide into SVN. I've still to fill out some of the sections in there but at least it's a start. It already has a fair bit of detail on Smooks and how it's used in the Trailblazer. | Congratulations Tom. However, what's the service API look like? How will someone go about replacing this transformation service with another one? I know you have ideas around this, so a separate forum discussion would be good. If this information is in the guide, just point me there. If it isn't, then hopefully the fallout from the subsequent discussion can be used to update the manual. anonymous wrote : | I'd really appreciate peoples feedback on this please! | | As I see it, one of the next big tasks re Smooks integration is that of storing the Smooks transformation configurations in an RDBMS (instead of XML) and fronting that with some sort of admin UI that will make it easier for a human to comprehend what transformations are taking place in a given message flow etc. | Add some JIRA tasks around your ideas, and assign them to 4.1. I'll take a look later today and we can have a chat about priorities. We already know that we need to improve our tooling, so I can see some of this happening in the 4.0 release. anonymous wrote : | I think this may be of particular interrest to people like David Degroff. I'll obviously be touching base with Mark before any of this however, because there may be other priorities. | | T. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975116#3975116 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975116

17 years, 7 months

1
0
0 / 0

[Design of JBoss ESB] - Smooks Transformation Integrated

by tfennelly

I completed round 1 of integrating Smooks into the ESB. This included modifying the Trailblazer to use the "SmooksTransformer" for one of the transfomrations. I've also started and commited a Message Transformation Guide into SVN. I've still to fill out some of the sections in there but at least it's a start. It already has a fair bit of detail on Smooks and how it's used in the Trailblazer. I'd really appreciate peoples feedback on this please! As I see it, one of the next big tasks re Smooks integration is that of storing the Smooks transformation configurations in an RDBMS (instead of XML) and fronting that with some sort of admin UI that will make it easier for a human to comprehend what transformations are taking place in a given message flow etc. I think this may be of particular interrest to people like David Degroff. I'll obviously be touching base with Mark before any of this however, because there may be other priorities. T. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975114#3975114 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975114

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: Why is DeploymentUnit.getDeploymentContext() deprecated?

by adrian＠jboss.org

"bill.burke(a)jboss.com" wrote : No, what i'm saying is that certain deployers need to deploy based on a concrete structure, not a classpath. Or in other words, the lines are too blurry for some deployers to be driven by classpath. | | This is why for EARS and WARS I think their lib/ and classes/ directories need to be treated as child DeploymentUnits. Then we need to unblur and take your intuition that these need to be DeploymentUnits. The EAR structure deployer doesn't even exist yet. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975111#3975111 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975111

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: Deployment Structure

by adrian＠jboss.org

"bill.burke(a)jboss.com" wrote : | I guess what I could just do is scope the name if the DeploymentUnit.getDeploymentContext().getParent() is not null. The deploy/ directory is not considered a DeploymentContext/Unit, right? | No, there should be a | public interface DeploymentUnit | { | ... | DeploymentUnit getParent(); | } | The getDeploymentContext() is only there so you can get on with doing things while we work these details out. It's upto you. You can either use the DeploymentContext, and I'll fix it later, or you can change the DeploymentUnit now if you think something is generically useful. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975110#3975110 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975110

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS isLeaf() vs isDirectory()/isFile()

by adrian＠jboss.org

NOTE: predetermined structure does not go through the structure deployers, there is no need, the user has already told you what they want. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975108#3975108 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975108

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS isLeaf() vs isDirectory()/isFile()

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | Yes, I know, but the existence of a WEB-INF is no longer a defining characteristic of a war. Think about sitting in jbosside with a single jsp or servlet that I want to deploy as a war. I view this as needing to setup a vfs repsentation of a war that is consumed by the structural deployers, and then deployed to the kernel. | I view this as a PREDETERMINED deployment context where you pass in the web metadata (it doesn't even need to be a web.xml file) and the classpath for the servlet (and its supporting classes). i.e. it is an adhoc deployment that does not follow the normal structure. I don't see the need to construct a complicated VFS context when the simple VDF abstraction can already cope with "programmatic structure" and can cope with circumstances where there is no spoon (metadata file). :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975107#3975107 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975107

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS isLeaf() vs isDirectory()/isFile()

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | I suppose this is where I'm currently out of synch. I see too much vfs related structure parsing happening in the structural deployers. I would rather have clearer steps to the structural part of deployment: | | 1. establish a vfs that encapsulates both the protocol for accessing raw files and structural layout in terms of a root VirtualFile and its children. By this I mean a tree of names is defined, and the basic attributes of the nodes in the tree are defined. This means marking files as ears, ejb-jar, wars, etc. | 2. structural deployers come along and identify the virtual file relationships in terms of classpaths, metadata descriptors, etc. | I completely disagree. The notion of ear, ejb-jar is not a VFS concept it is a deployment concept. I'd be more inclined to make the "isArchive" a deployment concept thus removing it from the VFS layer into the structure deployers. But this would mean the structure deployers would need to be an externalisable component such that the VFSScanner instead of doing: | if (file.isLeaf()) | deploy(file); | else if (file.isDirectory() || file.isArchive()) | deploy(file); | else | scan(file); | It would do: | if (structureDeployers.isDeployment(file)) | deploy(file); | else if (isLeaf() == false) | scan(file); | But there is a missing else in the last part where we have an unrecognised leaf node that is unknown to the main deployer so it can't report it as "undetermined structure". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975106#3975106 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975106

17 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Portal Integration

by Alkero

I want to restart to contribute to jBpm, and to work on the portal integration if it's ok for you. It seems that firstly it will need to refactor the identity component. I haven't started to look at this particular point, so any advices is welcome ! Regards, David View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975087#3975087 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975087

17 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: 3.2 alpha 1 release status

by Alkero

anonymous wrote : 3.1, 3.2, 3.3, ... can have changing database schemas Is it documented somewhere ? Regards, David View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975086#3975086 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975086

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Incorporating Remoting http transport into Messaging

by ron_sigal

I'm copying this from the Remoting forum in case nobody has a watch on it. "timfox" wrote : | Messaging has no requirement to get acknowledgements that messages have been delivered to the client side. | There may be no formal messaging requirement for acknowledgements, but it seems to derive from the current implementation. Currently, messaging delivers messages from the server to the client by the synchronous org.jboss.remoting.Client.invoke() method, and ServerConsumerEndpoint.stop() waits for the completion of the call to invoke(): | this.executor.execute(new Deliverer()); | //Now wait for it to execute | Future result = new Future(); | this.executor.execute(new Waiter(result)); | result.getResult(); | Now, if you want to have the client side poll for messages, then the completion of the Deliverer only means that the messages have been handed over to Remoting. My understanding is that you want all messages that have left ServerConsumerEndpoint to be delivered to MessageCallbackHandler before concluding ServerConsumerEndpoint.stop(), and the only way I can see to get that information is to get an acknowledgement from the client side. Let me know if I've misinterpreted something. "timfox" wrote : | (The HTTP transport might use acknowledgments internally to manage it's buffer -although I am not sure that is the best way to do it- but that's an implementation detail of the HTTP transport). | My understanding is that this issue isn't specific to the HTTP transport. Messaging's current use of the socket transport involves a callback org.jboss.remoting.Client on the server side contacting a ServerSocket on the client side. I thought you wanted to avoid the client side ServerSocket in all cases. Or does this restriction apply only to the HTTP transport? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975075#3975075 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975075

17 years, 7 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 September 2006