-
15. Re: 1.4.1.GA ready
"anil.saldhana@jboss.com" wrote:
What will make the messaging project more agile? I opened a critical security bug last week and I am still no where in sight of even a snapshot release here. :)
Well... AFAIK the critical security bugs were fixed in the branch within hours of you opening the report.
The vast majority of the delay has been in waiting for resolution into the JCA issue which was causing the TCK to fail, which turned out to be not JBM's fault, but a misconfig in JCA on the app server.
The failure to ensure that the JBM dependencies are the same as the AS dependencies was indeed our fault - but I'm sure Clebert will sort this out quickly. -
16. Re: 1.4.1.GA ready
"timfox" wrote:
"anil.saldhana@jboss.com" wrote:
What will make the messaging project more agile? I opened a critical security bug last week and I am still no where in sight of even a snapshot release here. :)
Well... AFAIK the critical security bugs were fixed in the branch within hours of you opening the report.
The vast majority of the delay has been in waiting for resolution into the JCA issue which was causing the TCK to fail, which turned out to be not JBM's fault, but a misconfig in JCA on the app server.
The failure to ensure that the JBM dependencies are the same as the AS dependencies was indeed our fault - but I'm sure Clebert will sort this out quickly.
One of the criteria for adoption of a project/product in a highly secure environment is the responsiveness of the implementers to security vulnerabilities and the speed with which patches are provided. So you succeeded in both.
I suggest we sort out build issues so that releases (deltas with security patches) happen faster. ;) Everyone should adopt the greatest messaging product on earth - JBoss Messaging. :) -
17. Doc issues WAS: 1.4.1.GA ready
JBoss 1.4.1.GA will be part of JBoss5, hence we won't require any library substitutions.
Because of that.. I have changed README.html to something simple as:JBoss Messaging Version 1.4.1.GA is a release made and tested exclusively for the JBoss 5.0.0.GA only and it should be part of the JBoss5 download bundle.
For the full description of this release, see the JBoss Messaging project JIRA.
Enjoy!
And there are other issues as well. For instance, The BindingManager on JBoss5 is now something much simpler where it just overrides properties.
The documentation is becoming a little complicated IMO. For instance on JBoss4 you need to replace libraries while on JBoss5 you don't as we are now part of the distribution. We are getting now things like If (JBoss4) do this ... else.. don't do anything.
The "examples" is another "example".... JBoss5 don't have the destinations created by default. so we need to change the howto on the documentation.
I guess we will need to differentiate the documentation between AS4 and AS5 as the operations is becoming fairly different now.
I guess it needs to be revisited/split as part of a bigger task.
Maybe making the JBossMessaging documentation part of JBoss5 documentation? -
18. Re: 1.4.1.GA ready
Howard,
Those libraries are used on ServiceContainer and our Mock tests only. There are maybe one or two usages on the source code, and they are not critical libs for the tests, and we will get eventual problems later (TCK, integration tests.. etc).
so, we will release with those libraries. We will eventually find a better way to couple with JBAS integration. -
-
20. Re: 1.4.1.GA ready
in the AS5 workspace, the thirdparty/jboss/messaging contains both "jboss-messaging.jar and jboss-messaging-client.jar"
but the client directory of the built AS ie. build/output/jboss-5.x/client directory contains jboss-messaging.jar rather than jboss-messaging-client.jar. Is this intended? -
21. Re: 1.4.1.GA ready
I thought the build at jboss5 is renaming jboss-messaging-client as /client/jboss-messaging.jar. If that's the real server, then that's wrong, but that's done at jb5 build.
-
22. Re: 1.4.1.GA ready
Clebert told me that he would do the release tomorrow and now I see Howard is doing it.
The reason is that I have been working for a full hour on your codebase and the following list is growing:========================================= anil@localhost:~/messaging/Branch_1_4$ svn stat M src/main/org/jboss/jms/wireformat/SessionCreateConsumerDelegateRequest.java M src/main/org/jboss/jms/wireformat/ConnectionCreateSessionDelegateRequest.java M src/main/org/jboss/jms/server/endpoint/ServerConnectionFactoryEndpoint.java M src/main/org/jboss/jms/server/endpoint/SecurityActions.java M src/main/org/jboss/jms/client/JBossConnection.java M src/main/org/jboss/jms/client/container/SessionAspect.java M src/main/org/jboss/jms/client/container/ConsumerAspect.java ============================================
Since JBoss Messaging is a heavy user of aspects, under a security manager, a permission check for "getClassLoader" is getting triggered which needs to be dealt in the messaging code base. We could have dealt it in AOP, but that is not correct.
Let Clebert do the release tomorrow. Once I fix your codebase, please send me a pillow to sleep during the day. ;) -
23. Re: 1.4.1.GA ready
I'll hold on the proces. I just need to verify our examples locally.
Anything needs me, pls let me know. -
24. Re: 1.4.1.GA ready
Yes Howard.. for now we just need to make sure the examples are working.
Anil... are you sure this won't affect performance?
So, you will probably check for System.getSecurityManager()==null, what means we would behave the same without creating an extra object when System.getSecurityManager()==null.
I have done some tests in the past, and when we do too many new PriviledgeBlocks, that really affects performance due to Garbage Collection on those objects. -
25. Re: 1.4.1.GA ready
"clebert.suconic@jboss.com" wrote:
So, you will probably check for System.getSecurityManager()==null, what means we would behave the same without creating an extra object when System.getSecurityManager()==null.
I have done some tests in the past, and when we do too many new PriviledgeBlocks, that really affects performance due to Garbage Collection on those objects.
Right, the code generated by AOP should have the check. -
26. Re: 1.4.1.GA ready
"scott.stark@jboss.org" wrote:
"clebert.suconic@jboss.com" wrote:
So, you will probably check for System.getSecurityManager()==null, what means we would behave the same without creating an extra object when System.getSecurityManager()==null.
I have done some tests in the past, and when we do too many new PriviledgeBlocks, that really affects performance due to Garbage Collection on those objects.
Right, the code generated by AOP should have the check.
The question is how do I get to the code generated by AOP to add the priv block. Am I looking at weaving in some aspects? -
27. Re: 1.4.1.GA ready
"anil.saldhana@jboss.com" wrote:
The question is how do I get to the code generated by AOP to add the priv block. Am I looking at weaving in some aspects?
You'll have to check with Kabir. That would be an aspect on a joinpoint...
The GA is going to have to be delayed for another week due to profileservice issues, so I would take a break after you send an email/post on the aop privileged block issue. -
28. Re: 1.4.1.GA ready
After a 5min IM chat with Clebert, he opines that the AOP code needs to be retrofitted (which I agree).
That means AOP generated code needs to insert the privileged block. Back to Kabir's land. I am off to sleep.
AOP which does the pointcut is basically invoking the getCLassloader op. It needs to appropriately generate the privileged block in the generated code. -
29. Re: 1.4.1.GA ready
"scott.stark@jboss.org" wrote:
"anil.saldhana@jboss.com" wrote:
The GA is going to have to be delayed for another week due to profileservice issues, so I would take a break after you send an email/post on the aop privileged block issue.
I do it for Dimitris. :) Anyway,
https://jira.jboss.org/jira/browse/JBAOP-675