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

[Design the new POJO MicroContainer] - Re: Multiple parsing implementation in RARDeployer

by alesj

"vickyk" wrote : | Ales , using the SRD approach means a lot of annotation changes in the MetaData . | I am just wondering how much task it would be to get this working with OMFD approach , since we have ObjectModelFactory ready for the ra.xml/jboss-ra.xml . | | How much change it would mean if we use OMFD which will be parsing the multiple xml's and using multiple ObjectModelFactory inside the merge(..) implementation ? | I have refactored the code, so you can now easily add your MultipleOMFD. - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/dep... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153574#4153574 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153574

17 years, 10 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JcaXAResourceRecovery

by jesper.pedersen

Jonathan, I've looked your changes in integration over and agree that we should take the specified interface for the first release. We can revise the SPI if we find specific use-cases later on. Feel free to add examples to the JBossTS documentation on how to inject the registry into other beans using the MC or JMX ;) I've some small changes to the integration project that I'll commit and then do the CR1 release. The work is tracked through http://jira.jboss.com/jira/browse/JBAS-5288 Thanks for your effort in this area. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153558#4153558 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153558

17 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Multiple parsing implementation in RARDeployer

by vickyk

"alesj" wrote : Your namespace is wrong, it should be a full name: xmlns="http://java.sun.com/xml/ns/j2ee" != namespace="j2ee". | Yes i see it working , not sure why I did not get it when I had placed the same ns earlier ;( Ales , using the SRD approach means a lot of annotation changes in the MetaData . I am just wondering how much task it would be to get this working with OMFD approach , since we have ObjectModelFactory ready for the ra.xml/jboss-ra.xml . How much change it would mean if we use OMFD which will be parsing the multiple xml's and using multiple ObjectModelFactory inside the merge(..) implementation ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153545#4153545 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153545

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: ESB vs. SOAP community

by Kevin.Conner＠jboss.com

"thomas.diesler(a)jboss.com" wrote : The home for this governance infrastructure, should also be JBossSOA and not JBossESB You obviously know something that I don't in that case, governance is external to the ESB in the same way that the SSO work is external. Governance affects us all, as does the SSO. When those teams come up with a solution then we will integrate with them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153541#4153541 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153541

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: ESB vs. SOAP community

by Kevin.Conner＠jboss.com

'thomas.diesler(a)jboss.com wrote : The benefit is, that JBossESB can have a different lifecycle than JBossSOA, With the current approach JBossESB determines the release cycle, which may be slower than what our community expects of JBossSOA. For example we cannot update JBossWS before JBossESB is ready for the next release. We are already working on a timeboxed release schedule, so we will have frequent releases. 'thomas.diesler(a)jboss.com wrote : Additionally, all folks that are currently involved in the various SOA projects should become members of JBossSOA. This is important to improve project integration. The integration point for JBossWS is through the app server and the EAP platform, why do we need to create an additional project for this? 'thomas.diesler(a)jboss.com wrote : Thirdly, the JBossESB project should only be concerned with ESB aspects and not try to act as an umbrella project, which it is not. It isn't acting as an umbrella project in the sense you mean. WS has a very specific integration point (ignoring ESB for now) and that is through the AS. Any additional work done by the ESB team lies with the ESB team. 'thomas.diesler(a)jboss.com wrote : Forthly, component updates and SSO should not be a property of the SOA-P they should be available to the community, develeoped and QAed in JBossSOA. Productisaztion should be the only concern of the SOA-P Which is why we have started a project to tackle that very issue :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153538#4153538 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153538

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: ESB vs. SOAP community

by heiko.braun＠jboss.com

anonymous wrote : | Thirdly, the JBossESB project should only be concerned with ESB aspects and not try to act as an umbrella project, which it is not. | Separation of concerns, right? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153533#4153533 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153533

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: ESB vs. SOAP community

by thomas.diesler＠jboss.com

Mark sais anonymous wrote : | Anyway, to cut a long story short: the whole governance infrastructure needs to have hooks into all of the projects (platforms) at various levels, not just for SAMM. | The home for this governance infrastructure, should also be JBossSOA and not JBossESB View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153530#4153530 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153530

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: ESB vs. SOAP community

by thomas.diesler＠jboss.com

anonymous wrote : | There is no such thing as JBossSOA | Exactly - and my point is that there should be a JBossSOA project that has a binary dependency on JBossESB like on any other project that goes into the SOA-P. The benefit is, that JBossESB can have a different lifecycle than JBossSOA, With the current approach JBossESB determines the release cycle, which may be slower than what our community expects of JBossSOA. For example we cannot update JBossWS before JBossESB is ready for the next release. Additionally, all folks that are currently involved in the various SOA projects should become members of JBossSOA. This is important to improve project integration. Thirdly, the JBossESB project should only be concerned with ESB aspects and not try to act as an umbrella project, which it is not. Forthly, component updates and SSO should not be a property of the SOA-P they should be available to the community, develeoped and QAed in JBossSOA. Productisaztion should be the only concern of the SOA-P anonymous wrote : | SOA-P should not touch project code - including the build. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153528#4153528 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153528

17 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Alternative vfs jar implementation

by alesj

"mstruk" wrote : | In UnpackTestCase I changed some assertions since the previous ones test some implementation details that are different when it comes to ZipEntryContext. Ales, have a look, maybe we can put some more sensible tests there. | OK, I'll have a look once full merge is done, e.g. NoCopy is included, ... I suspect it's an issue with trunk having NoCopy by default, and when we read the nested jars, your impl already copies the file, where in our trunk case we don't - and that's what the test expects - hence assertEqual. "mstruk" wrote : | I also commited an optimization of the way file handles are released. I mentioned that it was too aggressive and causing a slight performance penalty. The slow down was not big, but was still noticable so I added an automatic asynchronous mechanism that releases files when they haven't been used for a few seconds. Currently this period is 5 seconds - hardcoded at the moment - can be made configurable. This fixes maybe about 80% of performance degradation which now looks to be ~1-2% jboss startup time relative to current vfs trunk. | I don't see why this asynch behavior is necessary. OK, I guess there must be a good reason for it, otherwise you wouldn't include it. Just couldn't find any good explanation of it in this tread. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153520#4153520 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153520

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Regression on Queue tests

by timfox

Destination should never be null. I'll sort it out today once I've done the ping stuff. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153517#4153517 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153517

17 years, 10 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 May 2008