[Design the new POJO MicroContainer] - Re: DESCRIBE phase - Dependency builders for MC Beans
by jason.greene@jboss.com
"alesj" wrote : "jason.greene(a)jboss.com" wrote :
| | but if the performance sucks as bad as this does, no one will use it.
| |
| Didn't you use this with PojoCache, but never noticed the bad performance? ;-)
|
Yes I inherited that choice, and I definitely noticed the problems, which is why I consider it's usage of AOP to be a failed experiment. Although we did tell people who cared about performance to use offline compilation when running under the AS. We also had all kinds of usability issues with it (most of problems reported where configuration errors, weaving issues, or stub compatibility problems).
The future replacement of PojoCache will take a saner JPA-like approach. BTW I don't mean to criticize JBossAOP, it's a good implementation of AOP. I just think we are using it solve problems that have way simpler and way faster solutions.
anonymous wrote :
| "jason.greene(a)jboss.com" wrote :
| | In general we should avoid expanding our usage of this until we know that the design is even fixable.
| |
| If Google can search a googol of entries in a split sec,
| I don't see why we couldn't do the same for a handful of beans and aspects.
|
| Kabir, what's the current search/matching mechanism?
| Can it be made plugable?
| Or how much would it take to improve that?
|
| Idea of Lucene or Hadoop (on a single cpu) comes to my mind ... :-)
| Or basically any decent BTrees impl should do.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230911#4230911
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230911
16 years, 11 months
[Design of JBoss ESB] - Re: DefaultJMSPropertiesSetter, DefaultESBPropertiesSetter a
by Kevin.Conner@jboss.com
"beve" wrote : Well I though that would not be needed. Filtering this out when a message enters at the gateway would work if there was only one provider in the bus. The ESB Message could never contain the the filtered out property and this would not be set on the jms message being sent internally, be it by the courier, or an outbound jms router.
Sure, the ESB message would not contain it and we would not set it but the provider may :)
"beve" wrote : If it's the same provider it should not have this problem. What am I missing ? :)
- Gateway reads message, transforms it (removing properties) and sends it to ESB listener.
- Oracle attaches the properties on sending.
- Listener reads message and, as it has no filter, attaches JMS_Oracle properties to ESB message
- We then send this message, then attempting to set banned properties.
So the properties always exist in Oracle, but are read-only.
"beve" wrote : Any property not starting with 'JMS' is considered an application property.
Sorry, I was asking for examples of those which start with JMS_. Are there any which we would want to initialise?
"beve" wrote : I really think that we should not filter at all and that it's strange that a jms provider can choose to reject another vendors properties like this. I would have thought that they would simply pick up the ones they are is interested in and ignore the others. I also thought that all jms header properties could be used in message selectors which would be another reason not to reject properties like this. But this is only my view of this matter. There might be other things to consider about this and perhaps rejecting is a valid implementation choice.
Well, the issue is what we pull into the ESB message and then set on outgoing messages, not really selectors. The reading of these properties are not prevented, but the setting of them is.
Perhaps we need to flip this on its head, have a set of provider specific *writeable* properties in the EPR to cover read-only *and* providers which do not ignore properties from other providers.
Kev
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230878#4230878
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230878
16 years, 11 months
[Design of JBoss ESB] - Re: DefaultJMSPropertiesSetter, DefaultESBPropertiesSetter a
by beve
anonymous wrote : But should this not be the responsibility of the gateway and EPR to handle?
Well I though that would not be needed. Filtering this out when a message enters at the gateway would work if there was only one provider in the bus. The ESB Message could never contain the the filtered out property and this would not be set on the jms message being sent internally, be it by the courier, or an outbound jms router.
anonymous wrote : This was seen with a single provider, oracle, we were not passing these between different providers.
If it's the same provider it should not have this problem. What am I missing ? :)
anonymous wrote : Do you have any examples of the properties which you are allowed to set?
Any property not starting with 'JMS' is considered an application property.
I really think that we should not filter at all and that it's strange that a jms provider can choose to reject another vendors properties like this. I would have thought that they would simply pick up the ones they are is interested in and ignore the others. I also thought that all jms header properties could be used in message selectors which would be another reason not to reject properties like this. But this is only my view of this matter. There might be other things to consider about this and perhaps rejecting is a valid implementation choice.
/Daniel
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230874#4230874
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230874
16 years, 11 months
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Creation of method tables in ClassAdvisor
by flavia.rainone@jboss.com
Jaikiran wrote : 2) The MethodHashing.methodHash() does some very specific/involved logic. How is it different from a normal method.hashCode()?
Taking a look at the J2SE API (http://java.sun.com/javase/6/docs/api/):
anonymous wrote : public int hashCode()
|
| Returns a hashcode for this Method. The hashcode is computed as the exclusive-or of the hashcodes for the underlying method's declaring class name and the method's name.
|
|
And at the MethodHashing.methodHash(Method) implementation:
public static long methodHash(Method method)
| throws Exception
| {
| Class<?>[] parameterTypes = method.getParameterTypes();
| StringBuffer methodDesc = new StringBuffer(method.getName()+"(");
| for(int j = 0; j < parameterTypes.length; j++)
| {
| methodDesc.append(getTypeString(parameterTypes[j]));
| }
| methodDesc.append(")"+getTypeString(method.getReturnType()));
| return createHash(methodDesc.toString());
| }
We can see that the Sun's version takes into account the name of the class and the name of the method, whilest the JBoss AOP implementation takes into account the name of the method, the types of the parameters and the reutrn type of the method. This is because we need an unique hash code per method:
long hash = MethodHashing.methodHash(declaredMethods);
| advisedMethods.put(hash, declaredMethods);
The complicated bits are in the createHash method:
public static long createHash(String methodDesc)
| throws Exception
| {
| long hash = 0;
| ByteArrayOutputStream bytearrayoutputstream = new ByteArrayOutputStream(512);
| MessageDigest messagedigest = MessageDigest.getInstance("SHA");
| DataOutputStream dataoutputstream = new DataOutputStream(new DigestOutputStream(bytearrayoutputstream, messagedigest));
| dataoutputstream.writeUTF(methodDesc);
| dataoutputstream.flush();
| byte abyte0[] = messagedigest.digest();
| for(int j = 0; j < Math.min(8, abyte0.length); j++)
| hash += (long)(abyte0[j] & 0xff) << j * 8;
| return hash;
|
| }
This method processes the string with a Message Digester, using the SHA algorithm, generating an unique byte array for each string. Then, the resulting array is transformed in a single byte by concatenating each first 8 bits of the first 8 bytes in the array. The result should be an unique hash code for each method. I'm not sure about this, since we are disposing of part of the resulting byte array, and using only the first 8 bits of the first 8 bytes (I guess I would have to ask to Mark Fleury, the author of this class). But I think that, if the hash code weren't unique, we would see failures at the JBoss AOP testsuite.
So, the short answer is that: Method.hasCode() is going to generate the same code for overloaded methods, but we need a hash code that is unique per method.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230869#4230869
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230869
16 years, 11 months
[Design of JBoss Portal] - Partial Refresh and RichFaces components on edit mode
by naspeh
Greetings
I use Jboss Portal 2.7.2 and RichFaces 3.3.0.GA.
Partial Refresh feature is switched on.
Edit mode contain several RichFaces components.
Received javascript error on load page:
"FUNCTION_NAME is not defined"
Where FUNCTION_NAME is rich faces function name (for example ProgressBar, when used rich:progressBar component).
I know workaround: put this component on view mode and set display: none.
But it isn't good solution.
I took some investigation with javascript.
Below javascript function definition isn't working:
<script type='text/javascript'>
| function test() {
| alert("test");
| }
| </script>
| <input type="button" value="Test" onclick="test()" /> // test() not found;
But when I change function definition it works:
<script type='text/javascript'>
| test = function() {
| alert("test");
| }
| </script>
| <input type="button" value="Test" onclick="test()" /> // test() is called;
I think problem is in javascript evaluation. In dyna.js.
Does somebody know better solution or how we can change javascript
evaluation?
Thanks a lot.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230863#4230863
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230863
16 years, 11 months