[JBoss AS Development] - Re: JBAS-7469, move bootstrap class loading into profile
by emuckenhuber
"scott.stark(a)jboss.org" wrote :
| I think this sould be part of the profile definition metadata and the current bootstrapURI processing replaced with the setup of a class loader bean deployment. I wanted to look more at the current bootstrap/embedded/shrinkwrap projects to what requirements exist along these lines.
|
Hmm yes i was thinking about adding additional information to the profile meta data as well - also related to virtual deployments. So it could make sense to do something like that replacing that.
In a different thread you were mentioning that deploy/ is a mess. It looks like the same is true for the common.lib folders as well. Most of the .jars would actually rather belong to a deployer or profile. Especially since classloading needs to process around 20MB everytime AS is started. This however seems to require moving more jboss deployments to a common location so that the distribution does not get too big.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266558#4266558
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266558
16 years, 4 months
[JBoss Portal Development] - setting up portlet user attributes for hosted portlets in jb
by chenwang
(my first post so my apologies if someone has already asked similar question) I'm in the process of using the portlet container to create a customised portal for our orgnisation (we don't need a fully featured portal solution as we've been there before and don't want to spend too much time changing what's been implemented) and so far so good thanks for the simple jsp taglibs. The problem I'm facing now is that most of our in-house portlets rely on some user attributes which were provided in previous portal and in order to make smooth migration, new portal should also populate those user attributes. According to portlet spec, provisioning of user attributes may not be a clearly defined requirement for portal but I wonder if jboss/gatein portlet container has some sort of integration or plugin point I can use to achieve this? I don't mind looking at the source, just need some clear direction. Thanks!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266528#4266528
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266528
16 years, 4 months
[JBoss Microcontainer Development] - Re: New features in classloading
by adrian＠jboss.org
"david.lloyd(a)jboss.com" wrote : Do any of these changes have negative performance implications? For example it looked like the changes for JBCL-128 might introduce some significant overhead. Might be worth doing some before/after profiling just in case?
It's only got extra overhead if you install a handler and then it depends upon what
the handler does.
I assume the one you are talking about is the ClassFoundHandler.
The only additional processing for no handlers are a few list == null checks
at the policy, domain and system levels.
The use case we are going to implement is for the Lazy Activation feature in OSGi.
In that case, you install a handler when you create the classloader, but then remove
it once the first class is loaded. So there is only overhead for one classloading request
and that is to implement the desired feature - i.e. start the services associated with
deployment.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266516#4266516
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266516
16 years, 4 months
[JBoss ESB Development] - Performance: Extracting security credentials from requests
by beve
As part of the performance work that David and I are working on I've been looking into ways to improve the performance when we extract security credentials from different message and transport protocols.
Currently we are using Smooks and the reason for that choice simply that was the quickest for me to implement.
I've now looked at using Stax and also at SXC (http://sxc.codehaus.org/Home)
I've taken one of the extractors which extract the Username element data and the Password elements data from a SOAP Security Header. The SOAP message is a String in this case and not a SOAPMessage object instance.
Following are the result that I've gathered:
Smooks
======
Test: WSSecurityInfoExtractorUnitTest.extractUserPassSecurityInfo
1ms 1969497ns
1ms 1985770ns
2ms 2154726ns
2ms 2325567ns
2ms 2807360ns
3ms 3157355ns
5ms 5156815ns
6ms 6649339ns
7ms 7066943ns
11ms 11248229ns
SXC
===
Test: WSSecurityInfoExtractorSXCUnitTest.extractUserPassSecurityInfo
16ms 16576305ns
18ms 18043196ns
23ms 23826942ns
24ms 24942720ns
28ms 28823322ns
31ms 31506149ns
32ms 32187070ns
45ms 45235491ns
59ms 59891821ns
93ms 93950116ns
Stax
====
Test: WSSecurityInfoExtractorStaxUnitTest.extractUserPassSecurityInfo
0ms 641808ns
0ms 647256ns
0ms 662552ns
0ms 666883ns
0ms 675334ns
0ms 678756ns
0ms 720663ns
0ms 743293ns
1ms 1771975ns
11ms 11028217ns
So I think Stax is the way to go here. If no one objects I'll create a Jira for this.
/Daniel
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266496#4266496
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266496
16 years, 4 months
[JBoss AS Development] - Naming over Remoting 3
by ron.sigal＠jboss.com
We're starting to look at adapting the Naming system to run over Remoting 3, so I'm opening this thread for any related discussion.
One issue has arisen in the context of JBAS-3151 "Convert HA-JNDI stubs to Remoting":
"ron" wrote :
| ...
| Is there anything wrong with HARMIClient and HARMIServer, other than the fact that they depend on RMI?
| ---
|
"brian" wrote :
| Not particularly, no. I think the main issues are 1) we want to unify as much as possible on a single remote invocation mechanism 2) get rid of myriad sockets opened by different services. I suppose the latter goes beyond the description of this JIRA as it involve converting HANamingService to use a Remoting connector instead of directly listening on port 1101.
|
"ron" wrote :
| It looks like there are two kinds of Naming listeners:
|
| 1. the "bootstrap" listeners in org.jnp.server.Main and org.jboss.ha.jndi.HANamingService, and
|
| 2. the actual service listeners: org.jnp.server.NamingServer and org.jboss.ha.framework.server.HARMIServerImpl
|
| So, we'd like to replace them all with handlers on a single Remoting connector (or, actually, the Remoting 3 version of of handlers and connectors).
|
"brian" wrote :
| The bootstrap listener part probably bears discussion on the jboss-dev list since it much more directly impacts stuff like end-user configuration (i.e. jndi.properties or other ways of setting the properties passed to new InitialContext()). The service listeners are more straightforward.
|
Any comments?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266436#4266436
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266436
16 years, 4 months
[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool
by flavia.rainone＠jboss.com
I found a random bug in ClassPool project.
Check this scenario:
1. An ear with two wars is created and deployed.
2. When the test invokes ClassPoolRepository.registerClassLoader, passing the ear class loader as an argument, it will trigger the creation of the ClassPool corresponding to the ear module. This creation is performed by JBossClDelegatingClassPoolFactory
3. The factory will perform a series of steps: creating the parent class pools(a), then creating the bootstrap classpools (b), creating the classpool domain(c), and finally creating the requested class pool itself(d).
4. In the given scenario, the class loader has no parent, so there is no parent class pool to be created (a).
5. When the factory reaches the bootstrap classpool creation is the problem. The "bootstrap" modules are the modules that have been registered in the RegisterModuleCallback but have no corresponding classpool yet. So, in the given scenario, the factory will iterate for a collection containing both war modules, as none of them has the corresponding classpool created yet.
7. Starting with the first war, this classpool creation will result in recursive call to JBossClDelegatingClassPoolFactory. It will again iterate for the unregistered classpool collection, which now contains only the other war. Again, we have a recursive call to create the classpool for this second war.
8. Reaching the second war, the factory will have no "bootstrap" classpools to create. So it will move on to step (c), creating the class pool domain. But the domain of the war is the ear classloader. So, it will create the classPool for the ear that was requested during step 2. It will then create the classpool for this second war and return.
9. Now, once the recursive call is returned to the context in which the classpool for the first war is created, the "bootstrap" cp creation is considered finished(b), and it will move on to creation of the domain classpool(c). Again, the domain is the ear classloader. As this step invokes ClassPoolRepository.registerClassLoader, it will be able of recognizing that a classpool for this ear has already been created, during the previous step.
10. Returning to the original context of the CP factory, in which the cp for the ear was being created. This step will try to create a CP for the second "bootstrap" module, that is the second war. Again, as this invokes ClassPoolRepository.registerClassLoader, it will recognize that this CP is created and consider this done (b).
11. Finally, the ClassPoolFactory finds the CP domain of the ear (app classLoader) (c) and creates the CP corresponding to the ear module (d). The problem is that this ear has already been created during step 8.
So, I thought that this "bootstrap" cp creation was not needed. We first create the parent pools and then the domain pools, so why would we need to create other pools? I resolved the problem getting rid the "bootstrap" cp creation. Unfortunately, this breaks the testNonDeploymentModule test. This test deploys a jar that contains the following beans.xml file:
<deployment xmlns="urn:jboss:bean-deployer:2.0">
|
| <classloader><inject bean="anys-classloader:0.0.0"/></classloader>
|
| <classloader name="anys-classloader" xmlns="urn:jboss:classloader:1.0" import-all="true">
| <capabilities>
| <package name="org.jboss.test.deployers.vfs.reflect.support.web"/>
| </capabilities>
| <root>${jboss.tests.url}</root>
| </classloader>
|
| <bean name="AnyServlet" class="org.jboss.test.deployers.vfs.reflect.support.web.AnyServlet"/>
|
| </deployment>
|
The module corresponding to anys-classloader is registered in the RegisterModuleCallback and would result in a CP creation during the "bootstrap" CP creation. As I commented out that part of the code, this test no longer works.
I was wondering is there is any way of identifying that specific type of scenario. If I could do that, I would generate the "bootstrap" CP only for "non-deployment" modules. This would avoid the problem in the scenario I described above without breaking testNonDeploymentModule.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266431#4266431
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266431
16 years, 4 months