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

by DirkBangel

Hi Mark, it is non native COM gateway and can be used even from non windows platform, that is the idea behind using http://j-interop.sourceforge.net . I could not follow what you meant by Web services option, is there a way to interoperate with COM runtime using Web Services? For sure, the web service could directly redirect the call to a COM server, but we intend to directly call the COM server. Do you mean such a scenario/ approach ? ----->[ESB] ---> [Listerner] ---> [Web Service] ---invoke dll or j-interop --> [Com Server] We intend: ----->[ESB] ---> [Listerner] --j-interop ---> [Com Server] Thanks for the reply, best regards, Dirk View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130524#4130524 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130524

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Another startup time regression

by dimitris＠jboss.org

The boot times I'm seing. I use 2 runs where the 2nd is faster because of the cached disk files, on XP. Intel Core2/T7200@2GHz/2GRAM WinXP/Sun15 With AOP 2.0.0.CR7 | 1st-run 2nd-run | minimal 4 4 | default 34 32 | all 55 55 | With latest AOP snapshot: | 1st-run 2nd-run | minimal 9 4 | default 41 27 | all 91 43 | It seems snapshot is slower, so I'm not changing the build now. More profiling is probably needed. BTW, maybe we should create a wiki with boot time results people see in various CPU/OS/JVM combinations, so we have a measure to compare against. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130520#4130520 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130520

18 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: COM Gateway

by mark.little＠jboss.com

Yes, a native COM gateway/bridge makes sense. Web Services (or SOAP/HTTP) would be an alternative option, but definitely not if performance is one of your criteria. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130516#4130516 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130516

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: future directions

by thomas.heute＠jboss.com

"PMN" wrote : | deployment: | It is currently provided through xml descriptors, some info are persisted, others are not. Why is that? At every start the entire xml descriptors are read and it is not clear what is persisted, when changes are detected, nor even if the xml descriptors are consistent. As a consequence there is no real design for extension or customization. Is there any future plan on this topic? | portlet.xml is a deployment descriptor. portlet-instances and *-objects are just here for people willing to pre-populate the portal objects (instead of using the admin portet or as compliment). The portal structure needs to be persisted. "PMN" wrote : | layout: | Layout assignment is done through xml descriptor. That is a bit rigid compare to the ability to dynamically associate a layout to a page through the event mecanism for example. Any plan to improve it? | Not sure i understand the question. You can change the layout programatically. "PMN" wrote : | platform / solutions: | A few features are "solutions" rather than platform building blocks - themes, navigation and dashboard injection. Any plan toward a clearer separation? | Yes, but note that core is already the glueing part. Some parts should be exported though. anonymous wrote : | theme: | Any plan toward an integration with YUI ? | No, but better plans ;) See the presentation framework discussions. GWT comes in mind as an example of presentation framework usage. It will be part of JBoss Portal 2.8 anonymous wrote : | These are just genuine questions, please do not see any criticism where there are not. Good questions, please see the presentation framework discussions and see if you have ideas to bring on the table, a lot of the work has already been done but it's always interesting to see in users use-cases fit in the model. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130510#4130510 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130510

18 years, 1 month

1
0
0 / 0

JBoss footprint on a linux platform

by Floyd Brown

I am evaluating JBoss for possible use, and the question of memory footprint was brought up. We would need to to use Web Services, JAXB and JDBC data connections. Is there a way to determine memory footprint as well as a ballpark for filespace requirements? This would be on an X86 based Linux system (2.6.23 - like Fedora Core 8) TIA, Floyd Brown

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Missing Classes from jbossall-client

by ALRubinger

The EJB3 TestSuite has exposed some missing classes in jbossall-client: http://jira.jboss.com/jira/browse/JBAOP-530 java.lang.NoClassDefFoundError: org/jboss/aop/WeavingStrategy | java.lang.NoClassDefFoundError: org/jboss/aop/pointcut/PointcutStats >From $JBOSS_HOME/client/javassist.jar: java.lang.NoClassDefFoundError: javassist/CtMember Also classes from $JBOSS_HOME/client/trove.jar and $JBOSS_HOME/client/jboss-metadata.jar I've hacked the EJB3 installer to manually patch jbossall-client.jar to include these (http://jira.jboss.com/jira/browse/EJBTHREE-1195), but a better approach would be to extract out the requisite classes from each of these projects into a x-client..jar, and then bundle into jbossall-client.jar. Or, what is the status of jbossall? Seem to remember a discussion about our deprecating it? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130501#4130501 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130501

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - future directions

by PMN

After reading a recent post on the user forum, it seems that a few subjects are touchy. Nevertheless there are a few topics that I like to ask: deployment: It is currently provided through xml descriptors, some info are persisted, others are not. Why is that? At every start the entire xml descriptors are read and it is not clear what is persisted, when changes are detected, nor even if the xml descriptors are consistent. As a consequence there is no real design for extension or customization. Is there any future plan on this topic? layout: Layout assignment is done through xml descriptor. That is a bit rigid compare to the ability to dynamically associate a layout to a page through the event mecanism for example. Any plan to improve it? platform / solutions: A few features are "solutions" rather than platform building blocks - themes, navigation and dashboard injection. Any plan toward a clearer separation? theme: Any plan toward an integration with YUI ? These are just genuine questions, please do not see any criticism where there are not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130499#4130499 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130499

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - vfsmemory urls are not working properly

by adrian＠jboss.org

I haven't debugged it to find the cause. I guess it is all the manual parsing that's in this code? :-) The problem occurs if you do | URL url = new URL("vfsmemory://MYID/directory); | URL sub = new URL(url, "sub"); | The actual URL comes out incorrectly as: vfsmemory://MYID/sub instead of vfsmemory://MYID/directory/sub The obvious hack is to do | URL sub = new URL(url + "/sub"); | but generic code won't be able to do this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130493#4130493 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130493

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: In/Un callbacks should be happening at Install

by adrian＠jboss.org

"alesj" wrote : When the installs fail, should we just unwind from the current index? | The thing is that uninstalls are different instances, and user can order them differently than the matching installs, or install perhaps even doesn't need to have matching uninstall. | But normally they do. :-) | | So, the only question is, what to do by default - execute all uninstalls or just from the failed install's index? I'd just execute all the unintalls and ignore errors. But you only need to do that if one of the installs has suceeded. Like you said, install/uninstall are not necessarily symmetric. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130492#4130492 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130492

18 years, 1 month

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: jndi lookup during restart

by bstansberry＠jboss.com

Sorry, I don't have a good answer for you. :( The RMI-stub caching issue can perhaps be fixed in Remoting using an approach similar to what I did in JNDI. I can only speculate on how Remoting could handle the tx timeout scenario you describe -- perhaps catch the InterruptedException, check the status of any tx associated with the thread and throw a meaningful exception on to the client? That's just speculation though, and seems hacky -- the Remoting guys would need to give you a better answer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130486#4130486 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130486

18 years, 1 month

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 February 2008