[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
[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
[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