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

[Design of JBoss Profiler] - Re: web interface not working.

by jesper.pedersen

The web interface isn't included in the distribution yet. You have to checkout the repository and build it yourself (./build.sh web). Please, note that it is work iin progress, so we could use help to finish the work. You can use the MBeans (thorugh jmx-console) as the article states in order to control the profiler. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184826#4184826 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184826

15 years, 10 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Can Jboss profiler 2 beta 2 using on Jboss 4.05?

by jesper.pedersen

We don't support 4.0.x out-of-the-box, but I don't see a reason why it couldn't work. This is however a community project as our focus in on AS-4.2 and AS-5.0. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184825#4184825 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184825

15 years, 10 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: JBoss Profiler 2 memory analysis

by jesper.pedersen

The currently beta is only able to count the number of object allocations - as listed in the overview.txt and individual class reports. We plan to provide a native backend that will add full support for all memory operations - f.ex. leak tracking, object sizes and so on. Work in this area has begone, but we could always use a helping hand. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184824#4184824 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184824

15 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Heavy usage of VirtualFileURLConnection

by mstruk

"alesj" wrote : | 2) change how we handle VFS URLs - same way we do it in pre-JBoss5 | Q1: what's the reason we don't return VFS URLs with temp paths? | VFS URL handling delegates to VFS handlers and contexts. The existence of a temp path is currently not guaranteed - depends on vfs settings and is an implementation detail. If contexts (handlers) were reused between URLs then there would be no performance problem. But as things are now, every getInputStream() request creates a new context. "alesj" wrote : | 3) implement some simple VFS caching | Q1: use real cache, e.g. LRU, or is SoftRef enough? | What would you cache? The most sensible thing to cache would be VFSContext ... "alesj" wrote : | Q2: we need to cache intermediate paths - getting different resources from same parent faster (this requires VFURLConnection impl change) | As long as you hold a context 'open', intermediate paths are automatically kept 'open' for fast access. "alesj" wrote : | Q3: transparent AOP usage - caching is an aspect? | We would have to identify the most appropriate join points for this. This opens another question - do we want to put cache interception only on URL VFS integration code or at VFS API level itself. - marko View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184798#4184798 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184798

15 years, 10 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: Secure Remote Classloading (JBREM-929)

by alesj

"david.lloyd(a)jboss.com" wrote : | (1) A Remote VFS scheme | Can you post some pseudo code on the subject, as I have no clue about remoting, but I know a thing or two on VFS. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184795#4184795 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184795

15 years, 10 months

1
0
0 / 0

[Design of JBoss Identity] - Re: JBoss Identity Design Preview

by bdaw

I created a separate topic for this: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=144427 "jeff.yuchang" wrote : "bdaw" wrote : .... | | Exactly the issue that I am worrying about with my suggestion, thats what I mean complexity on the implementation, and say 'I just bring about this issue'. ;-(. We may keep it as it is now, cause I haven't come up a easy way to accomplish this change. Not sure others will have a better way? | | -Jeff View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184792#4184792 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184792

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments

by alesj

"pete.muir(a)jboss.org" wrote : | Sure, it doesn't make sense to *you*, but this is exactly the way any end user will see it - "Why does JBoss 5 take ~4s to open an inputstream!!!!????" ;-) It would be naive to assume that applications don't open files (let alone third party frameworks), and it's not viable to tell them "use VFS", not least because it's not a standard... Do I make sense? Or am I missing an important piece of the puzzle? Missing a puzzle --> This is dev forum == no users. ;-) Shane's results won't surprise me, since we know what they'll show: - direct temp URL vs. URL->URLConnection->VFS We're here to find a solution, not performance numbers. ;-) I've started a MC dev post here: - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184788#4184788 As the problem is more general than Seam's usage. Please post any suggestions there, and we'll come back here to try them. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184789#4184789 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184789

15 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Heavy usage of VirtualFileURLConnection

by alesj

When dealing with VFS URLs pointing to some nested resources, things get horribly slow due to huge VirtualFileURLConnection usage. Here is where things are explained a bit more on real Seam example: - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184779#4184779 The possible solutions I see. 1) try to impl those Seam use cases directly on VFS - same way we do it for Deployment and CL Q1: can we really do it for all cases? Q2: what about other non-integrated frameworks in JBoss5? 2) change how we handle VFS URLs - same way we do it in pre-JBoss5 Q1: what's the reason we don't return VFS URLs with temp paths? 3) implement some simple VFS caching Q1: use real cache, e.g. LRU, or is SoftRef enough? Q2: we need to cache intermediate paths - getting different resources from same parent faster (this requires VFURLConnection impl change) Q3: transparent AOP usage - caching is an aspect? Any other ideas? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184788#4184788 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184788

15 years, 10 months

1
0
0 / 0

[Design of JBoss Identity] - API Model - Plain pojos or not...

by bdaw

Some of ideas discussed in the other topic (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=144427) ends up in a more general question on how API model objects should be designed/implemented. Should the Identity/Group/Role objects be plain pojos or expose some of management operations. 1) Plain POJOs - Identity/Group/Role objects keep minimal information about Id/Name/Type. They are easily seriazible and there are no problems with closed session (like with detached hibernate entities). With this approach even getDescription method should be removed as it needs a session reference to retrieve the value. 2) Model objects keep reference to the associated session and expose some of management operations like Group.associateGroup(Group group) | Group.associateIdentity(Identity identity) The idea is to keep all methods in the managers but duplicate some of them in Identity/Group/Role interfaces to expose convenient use: | employeeGroup.associateIdentity(jackBlack) | | and | | identitySession.getRelationshipManager().associateIdentity(employeeGroup, jackBlack) | Both approaches have pros and cons.... With the second approach serialization requirements can be painful and we may end up with things like SessionClosedException... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184784#4184784 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184784

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments

by shane.bryzak＠jboss.com

No problem, here's a comparison (running in JBossAS 4.2.3): 11.7% - 2,649ms - 44 inv. org.jboss.seam.deployment.SeamDeploymentProperties.addPropertiesFromResourceBundle Averaging out the CPU time per call we get about 60.2ms. Compare this to JBossAS 5 which is > 4000ms, and it's a significant difference. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184783#4184783 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184783

15 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2008