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

[Design of JBoss ESB] - Re: JBESB Data Transformation - Maintenance and Design

by tfennelly

Thanks Dave. I'll take a look at this over the weekend. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961561#3961561 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961561

17 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JBESB Data Transformation - Maintenance and Design

by ddegroff

anonymous wrote : I would be interested in seeing more detail on your ideas in this area. In terms of developing tools/wizards for configuring/building-on an ESB Transformation Service, I think the devil will be in the detail!! That said, I think there's a lot that could be done with wizards/designers etc to make the easy things easy, allowing you to concentrate more on the nasty parts of transformation. This would be a major learning process for me anyway - how to develop a designer/wizard that is successful in making the Transformation Service easier to use, without getting in the way when the going gets tough!! Your wish is my command: http://www.ehealthconnect.net/ehc/jbossesb-xl-functional_spec.pdf This is my first cut at a functional spec. for the proposed D/T functionality. I completely agree about where this fits in the phased development cycle for JBESB. Where I find myself right now (hiring on with a JBoss client 1 Aug, with a project requiring transformation beyond the complexity I published under another topic), this issue may present itself as a priority for current and near-term projects. But, this is a parallel design/ development project, not something I would recommend injecting into JBESB right away. Thanks in advance for your attention to this issue. And, as always, any thoughts about this topic are gratefully incorporated as appropriate. Best Regards, David View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961558#3961558 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961558

17 years, 9 months

1
0
0 / 0

[Design of Security on JBoss] - Re: EJB getCallerPrincipal inconsistencies

by wonnekeysers

Scott, Looking at http://fisheye.labs.jboss.com/viewrep/JBoss/jboss-ejb3/src/main/org/jboss... the method getCallerPrincipal() throws an IllegalStateException when the principal is null. Is this the desired functionality, because the EJB3 spec mentions the following: anonymous wrote : If the anonymous principal type was propagated or the identity token was absent, then EJBContext.getCallerPrincipal().getName() returns a product-specific unauthenticated principal name. I ran into this problem in a unit test running inside embeddable ejb3 where the ejb did not have security configured at all... Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961551#3961551 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961551

17 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Use of InvocationContext vs. explicit Option in the API

by ben.wang＠jboss.com

I understand that in the new 2.0 API, you will expose InvocationContext for the user as a thread local variable. Right now, I can see that Option can be set there such that all subsquent code will be affected by that Option. PojoCache 2.0 also has the need to use an Option to set a BR region. I am debating now to either 1) to be consistent with Cache/Node such that I also use a similar InvocationContext to set it explictly, or 2) overload my APIs (3 of them) with an Option parameter, e.g., cache.attach(id, pojo, option). I am inclining to go with the first one. However, after thinking it over, I am not that comfortable with it yet. Manik, I hope you can convince me. :-) The good thing about setting Option in a threadlocal variable is that there is not extra APIs so the interface is cleaner. However, IMO, InvocationContext should belong to the SPI per se, not the API. That is, user should not see it. Af far as I can see, currently InvocationContext only carries Option that is interested to a caller. In addition, a user will need to: {{{ Option option = new Option(); InvocationContext.getCurrent().setOption(option); cache.put(fqn, key, value); ... }}} Nothing wrong but I just think it is relatively prone to errors. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961521#3961521 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961521

17 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: next steps for the console webapp

by kukeltje

I disagree that requireing JEE 5 for the console is a valid option. Many serious organizations have environments that have to be identical. I myself cannot get a JEE 5 environment just for the console/webapp (in fact, I cannot get one at all). Since I do some of the development indirectly in the time of my employer, this will certainly not be appreciated and most likely result in withdrawing this 'time'. Regarding the components, I would try to to base the tasklist (sortable, pageble) on an existing datatable. The myfaces one (in tomahawk) fits nicely. The taskform component should also not be to difficult View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961518#3961518 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961518

17 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: next steps for the console webapp

by tom.baeyens＠jboss.com

"svetzal" wrote : | My hope over the past several months has been to gain insight into writing complex JSF components, and thus far I'm not particularly keen. There are a lot of rough edges throughout MyFaces and JSF. | sure a task list and a task form JSF component should be possible, no ? "svetzal" wrote : | The alternative is tying ourselves to a specific implementation (MyFaces) and using their existing infrastructure(s) for things like external resource binding. | How does everyone feel about an explicit tie to MyFaces? i don't see why an explicit ty to myfaces would be required. also i don't get what you mean with external resource binding. could it be that these problems can be solved with a thread local ? simple version of the idea is to create a http-filter that sets up the environment which is able to fetch the external resources and store this environment in a thread local somewhere. then inside of your JSF components, you can access the external resources through the environment. it should be very similar to how we do it now in the console. i think. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961510#3961510 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961510

17 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: next steps for the console webapp

by tom.baeyens＠jboss.com

about the infrastructure requirements of SEAM: i'm not so sure if SEAM adds too much infrastructure. especially since you should consider that these requirements DO NOT propagate to the engine. jBPM 3.x will remain runnable on JDK 1.4.2 The two main requirements are: Java 5: i think that should not be a big problem by now for the console. I do think it would be a big problem for the jbpm core runtime library. EJB3: That can be packaged with the microcontainer and is runnable on a standard java environment. SEAM is usable in tomcat, jboss and in other app servers. While this seems tricky to me, i have full confidence in Gavin that it will work 'seamless' :-) any other requirements i forgot ? what is your opinion on those 2 ? again: note that this is for jbpm console. you could run jbpm console on a separate tomcat, while your jbpm runtime environment is running in a jboss or other environment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961509#3961509 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961509

17 years, 9 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - Re: JBMS Alternate Datastore

by acoliver＠jboss.org

For clarification, the probelm is not specific to JBMS. You will have to come up with a reliable storage solution for any mail server. One configuration is to have JBMS use something locally for the queue persistence, but that has its own reliability issue. Ultimately you need to decide what your tollerance for failure is and pick a storage solution that meets those needs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961483#3961483 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961483

17 years, 9 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - Re: MessageData getBoundary() bug?

by acoliver＠jboss.org

yes. That is a bug. Please post it in JIRA. Even better if you can add a patch. It ought return null if no boundary. Oddly it doesn't seem like I've had probelms in head sending and receiving plain text messages. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961481#3961481 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961481

17 years, 9 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - Re: MessageData getBoundary() bug?

by acoliver＠jboss.org

yes. That is a bug. Please post it in JIRA. Even better if you can add a patch. It ought return null if no boundary. Oddly it doesn't seem like I've had probelms in head sending and receiving messages. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961480#3961480 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961480

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