December 2006 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Add mc 2.0.0.Beta to maven repo

by scott.stark＠jboss.org

I added the 2.0.0.Beta contents to the repository.jboss.com/maven2 repo using the groupId of jboss and the following artifactIds: jboss-aop-mc-int jboss-container jboss-dependency jboss-deployers jboss-kernel Not sure all of the dependencies are correct so if you have trouble building let me know. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992153#3992153 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992153

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: vfs* based URLs

by bill.burke＠jboss.com

I have finished "vfs" URL based support. I have tested it with the virtual testsuite and a snapshot of JBossas head. I need to test it with the latest head before I make it official. Code is committed in microcontainer SVN. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992136#3992136 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992136

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: How does SErviceDeployer register with MC

by weston.price＠jboss.com

Cool. I will review. I should be able to address your questions regarding profile/JCA when I see the doc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992124#3992124 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992124

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: JACC: Policy Configuration needs to be linked with child

by scott.stark＠jboss.org

No, because the dependency on a particular implementation of the security aspect is not deployment level metadata. The deployment specifies the security domain and j2ee permissions/roles. Its a server configuration that says the security aspect is using jacc and the associated deployer introduces the metadata for the components that implement jacc. That is not to say in the future we might have directives that control the deployment processing, but we should not be overloading the legacy descriptors with new aspects. The security configuration aspect should be another layer independent of jboss-app.xml, jboss.xml, etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992123#3992123 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992123

18 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: JSR88 updated with a StreamingTarget implementation

by scott.stark＠jboss.org

Yes, that is the simple add a deployment sequence. We don't care about how the service is packaged for this scenario. Something has to care about the packaging in terms of how admin changes are applied to the deployment repository, but there are a lot of details to flesh out. The issue is that, for a given deployment: - there has to be a management interface representation that allows a tool to perform changes without the jboss server running - there has to be a mapping from the management interface properties to the deployment metadata the admin changes apply to, and/or a mapping to the runtime component properties the changes apply to. There can be a management property that only applies to the deployment metadata and requires a restart, applies to only a runtime mc component property, or applies to both. The change has to be a delta of some form in the deployment repository. How this is stored and the override applied depends on the management interface to deployment metadata/component property mapping. The RARDeployer port certainly affects the mapping, but should not affect the managment interface. I'm working on a profile service overview/state of being description to put out tonight as background for the parties to use as a basis for what we want to do with a managment aspect. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992122#3992122 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992122

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: How does SErviceDeployer register with MC

by scott.stark＠jboss.org

I'm working on an overview of the profile service and the expected usecases of management views mapping to deployment metadata/component properties. I'm working to get something out tonight as we want to start talking about the managment aspects of jboss5 and their intersection with the mc/vdf as part of the post cts call on Fridays. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992120#3992120 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992120

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: PortletContext and StateEvent design

by julien＠jboss.com

what would be the actual changes ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992119#3992119 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992119

18 years, 1 month

1
0
0 / 0

[Design of Kosmos] - Re: Performance with many projects

by bjoy

I have tried modifying the ehcache.xml to point at a different directory. The startup still took 10 minutes and the data/index files created for the cache were both 0 length. I compared the log entries made on the first run against the last and noticed that there were 300 more entries logged in the last run. The first run did not have entries like the following: http-8080-Processor22, 07-Dec-2006 22:14:52, unauthenticated, DELETE, 204 "No Content", 250 ms, /files/kosmos-cache/1165528202000_http%3A%2F%2Fussvd-bjoy%3A8070%2Fsubversion%2FSampleProject%282%29%2Ftrunk_files_per_file_type_small.png Given that all the extra log entries seem to be like this one, that only shows where approximately 75 seconds of the extra time is being spent. And since I changed the cache location (and the cache staying zero length after VM shutdown), I don't understand why the last run was finding anything to delete. I was expecting startup behavior to match the timing of the first run. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992115#3992115 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992115

18 years, 1 month

1
0
0 / 0

[Design of JBossXB] - Re: Recent tests

by alex.loubyansky＠jboss.com

CollectioOverridePropertyUnitTestCase is fixed now (JBXB-93). Adrian, you were right in that interceptor.add() overrides handler.setParent(). I apologize. I guess the reason I got confused is that it works not the way I would like to :) It would be better to have use-local metadata/interceptor/handlers that could override their global defaults. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992108#3992108 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992108

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - PortletContext and StateEvent design

by chris.laprun＠jboss.com

I think that we could simplify the current StateEvent/PortletContext handling in the context of state management of portlets. The current design, while based on subclasses, does not lend itself to polymorphism. For example, in FederatedInstanceContext: if (event instanceof PortletClonedEvent) | { | PortletClonedEvent pce = (PortletClonedEvent)event; | PortletContext clonedContext = pce.getClonedContext(); | ctx.onStateEvent(new PortletClonedEvent(reference(clonedContext))); | } | else if (event instanceof PortletModifiedEvent) | { | PortletModifiedEvent pce = (PortletModifiedEvent)event; | PortletContext modifiedContext = pce.getModifiedContext(); | ctx.onStateEvent(new PortletModifiedEvent(reference(modifiedContext))); | } I don't see the benefit of having such a split between different kinds of events. The above code could be simplified if StateEvent was taking on more responsibilities: PortletContext portletContext = event.getPortletContext(); | ctx.onStateEvent(new StateEvent(reference(portletContext)), event.getType()); In this new design, StateEvent would not be subclassed but contain a type field for these cases where the exact nature of the event needs to be known. This would only work with a rework of PortletContext. I think that PortletContext should add a getState method. It's perfectly fine for a PortletContext to have an optional state (this is how WSRP works after all). We could keep the subclass to optimize memory usage and avoid to carry a byte[] on all PortletContexts even these which don't have a state. getState would return null if there is no state, StatefulPortletContext would override getState to return the state. I think that these modifications would make dealing with state events easier and simplify our code. What do people think? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992106#3992106 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3992106

18 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums December 2006