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

[Design of JBoss Labs] - Re: Wrong headers slowing www.jboss.org down

by adamw

Hello, well, I get the following: | wget --header='If-Modified-Since: Fri, 01 Jun 2007 01:41:08 GMT' http://www.jboss.org/file-access/default/theme/images/common/jbossorg_log... 10:12:11-- http://www.jboss.org/file-access/default/theme/images/common/jbossorg_log... | Resolving www.jboss.org... 64.74.196.163 | Connecting to www.jboss.org|64.74.196.163|:80... connected. | HTTP request sent, awaiting response... 304 Not Modified | So I think that the 304 is working. Anyway, we'll change the settings for expires soon. Thanks, Adam View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143800#4143800 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143800

17 years, 12 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ClassLoader behaviour on remote clustering tests

by kabir.khan＠jboss.com

"timfox" wrote : I'm not happy with this lazy generation - can we just switch back to the non lazy generation please? Then use the ClassicInstrumentor. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143789#4143789 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143789

17 years, 12 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ClassLoader behaviour on remote clustering tests

by timfox

I'm not happy with this lazy generation - can we just switch back to the non lazy generation please? (I.e. the way that AOP used to work) 10 seconds is way too long. Also bear in mind that messaging systems must not provide reasonably stable latency, Suddenly pausing for 10s is not an option. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143778#4143778 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143778

17 years, 12 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ClassLoader behaviour on remote clustering tests

by flavia.rainone＠jboss.com

Oh,yes. I forgot to let you know how much time is being taken with this piece of the code. The 348 calls to the joinpoint class generation is taking a total of 9548ms to execute. The 205 real class generation that takes place takes a total of 9137ms. Notice that I haven't evaluated the isolated performance during execution of the failed test methods. All these numbers regard the performance of the execution of the whole test execution (i.e., the 8 test methods). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143759#4143759 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143759

17 years, 12 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ClassLoader behaviour on remote clustering tests

by flavia.rainone＠jboss.com

Clebert, I am seeing 348 calls to the joinpoint class generation code during the execution of your tests. The weird is that there are only 28 entry points (method wrappers) that call this code. 8 of those 28 entry points are called thousands times each. The other 20 are called only a few times each, and if we sum up all the times they are called, we will get to 339 calls. Thanks to the cache of generated classes, only 205 of the 348 calls to the generation of classes actually result in a class generation. The other calls just retrieve classes from the cache. Anyway, I don't see why would the class generation ocurr so many times if you told me that those tests don't perform any dynamic addition/removal of aspects. My initial thought is that we should see one class generation call for each one of those 28 methods, and this should occur the first time those methods are called. Probably I'm missing something here... I'll continue looking for what is causing this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143758#4143758 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143758

17 years, 12 months

1
0
0 / 0

[Design of EJB 3.0] - Pulling security out as a separate module

by anil.saldhana＠jboss.com

in the ejb3 landscape. Carlo wants this. I am still not aware of the need for this, apart from a cleaner ejb3 core. What about the security interceptors (AuthenticationInterceptorv2, RoleBasedInterceptorv2 etc) in ejb3 core? Should they be moved to the ejb3-interceptors using the ejb3-security module code base? Now that the v1 interceptors are gone, I can rename the v2 as regular interceptors. So, security codebase goes as ejb3-security module + security interceptors go into the interceptors module. Is this ok? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143756#4143756 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143756

17 years, 12 months

1
0
0 / 0

[Design of JBoss Portal] - Re: JBoss Portlet Container integration into 2.7

by julien＠jboss.com

I have adapted the content provider framework for rendering to use public render parameters as it was planned. In order to be content driven a portlet needs to declare and manage the public render parameter "uri" with the namespace "urn:jboss:portal:content". At runtime the portal will set the declared parameter with the window contained URI. What is remaining to be done in that area is : 1/ update of the faces portlet component to handle a portlet generated event as a JSF event 2/ implement a special event that signals the end of the configuration activity during content edition using the same "urn:jboss:portal:content" namespace with an appropriate name. When this event is received it should tells the JSF admin portlet that content is configured. Today that already exists but relies on a special action parameter which is the previous way to communicate. I experienced the impossibility to use the portlet content editor in the admin due to stack traces, so that should be solved asap. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143747#4143747 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143747

17 years, 12 months

1
0
0 / 0

[Design of JBoss Portal] - Re: JBoss Portlet Container integration into 2.7

by julien＠jboss.com

I just did the implicit event distribution that use also the same event qname distribution strategy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143734#4143734 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143734

17 years, 12 months

1
0
0 / 0

[Design of JBoss Portal] - Re: JBoss Portlet Container integration into 2.7

by julien＠jboss.com

I have added support for public render parameters with implicit sharing. The matching strategy uses the "same qname" strategy. There is an example that I added in basic samples that show portlet sharing parameters with various option to manipulate them. I have also added back support for the app-id feature that was making some of our samples not work correctly. I added an app-id element in jboss-portlet.xml and am in favor of deprecating jboss-app.xml (but keep support for it in 2.7 with a warn on the console). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143732#4143732 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143732

17 years, 12 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Sample JRPP client and server code?

by trustin

Uh... checked in the patch by mistake. Could you please review it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143708#4143708 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143708

17 years, 12 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 April 2008