January 2007 - jboss-dev-forums - Jboss List Archives

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Array interception needed for jboss cache

by jason.greene＠jboss.com

This looks great, however, it might be a good idea to detect local array references that are never passed outside of a method body. Consider something like the following: | { | long[] hi = new long[n]; | long f = 0, g = 1; | for (int i = 0; i < n; f += g, g = f - g, i++) hi = f; | } | Detecting this as local would prevent N method invocations and N memory barriers (potential cpu cache flushes). This would be slightly complicated to detect, but worth it IMO. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000733#4000733 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000733

19 years, 2 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Help needed on Deploying a Struts Application as a portl

by scott.stark＠jboss.org

Don't post user question in the design forums. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000730#4000730 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000730

19 years, 2 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: JBoss AOP standalone build

by dimitris＠jboss.org

No JIRA issue, thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000727#4000727 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000727

19 years, 2 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Help needed on Deploying a Struts Application as a portlet o

by hussain_rangwala

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - ServiceMetaData parsing needs to be pulled out of

by scott.stark＠jboss.org

An issue I have run into with testing deployment and editing of data sources via the profile service is that the metadata attachments associated with a service deployment is not getting parsed unti the real deployer is run during the component traversal. The ServiceDeployment attachment services is not being populated until here: | Thread [main] (Suspended (breakpoint at line 98 in ServiceDeploymentDeployer$ServiceDeploymentVisitor)) | ServiceDeploymentDeployer$ServiceDeploymentVisitor.deploy(DeploymentUnit, ServiceDeployment) line: 98 | ServiceDeploymentDeployer$ServiceDeploymentVisitor.deploy(DeploymentUnit, Object) line: 75 | ServiceDeploymentDeployer(AbstractRealDeployer<T>).deploy(DeploymentUnit) line: 89 | ServiceDeploymentDeployer(AbstractComponentDeployer<D,C>).deploy(DeploymentUnit) line: 72 | ServiceDeploymentDeployer(AbstractSimpleDeployer).commitDeploy(DeploymentUnit) line: 52 | DeployerWrapper.commitDeploy(DeploymentUnit) line: 165 | MainDeployerImpl.commitDeploy(Deployer, DeploymentContext, Set<DeploymentContext>) line: 557 | MainDeployerImpl.process(int, int) line: 495 | ProfileServiceBootstrap.loadProfile(String) line: 352 | ProfileServiceBootstrap.bootstrap() line: 248 | ProfileServiceBootstrap(AbstractBootstrap).run() line: 89 | ServerImpl.doStart() line: 403 | ServerImpl.start() line: 342 | Main.boot(String[]) line: 210 | Main$1.run() line: 508 | Thread.run() line: 595 | In order for the profile service to be able to build a pojo metadata model of a deployment that can be overriden by tool edits, all metadata that is subject to admin edits needs to be available before the Deployer.CLASSLOADER_DEPLOYER level of deployers have processed the deployment. The basic logic is: | // Associate the raw deployment with the profile | VirtualFile deployment = (raw deployment pushed by the user) | AbstractDeploymentContext ctx = new AbstractDeploymentContext(deployment); | profile.addDeployment(ctx, phase); | | // Process the base deployment to obtain the pojo metadata view | mainDeployer.addDeploymentContext(ctx); | Collection<DeploymentContext> ctxs = mainDeployer.process(-1, Deployer.CLASSLOADER_DEPLOYER); | checkIncomplete(); | for (DeploymentContext d : ctxs) | { | // Save the pojo metadata view of the raw deployment in the profile | profile.updateDeployment(d, phase); | } | | // Determine the pojo metadata properties that can be edited | Map<String, ManagedObject> mos = mainDeployer.getManagedObjects(ctx); | // ManagedObject edits map an override set of pojo metadata stored in the profile via an update interceptor aspect | Subsequent deployment of deployment with edits starts at the Deployer.CLASSLOADER_DEPLOYER level of deployers, bypassing all of the metadata processing deployer as the associated DeploymentContext.getPredeterminedManagedObjects() has been populated from the admin edits store in the profile. There is also another issue with the granularity of the Map<String, ManagedObject> for a deployment like a service descriptor. For this you have a single attachment of type ServiceDeployment which contains the ServiceMetaData for the mbeans, which contains the attributes that correspond to the ManagedProperty objects one would edit. The simplest view of a datasource would just have the jndi name and jdbc url as ManagedPropertys. What the admin tool needs to see is an inverted view where it gets a set of ManagedPropertys to edit, and these changes get mapped onto the attachment settings. While this can be setup inside the server via aspects, when a remote tool queries the properties and edits them, the aspects are lost. Essentially the same issue as entity beans becoming detached. Either I need to leverage logic similar to what hibernate does, or have an xpath like attribute in a ManagedProperty that allows the tool to submit a set of changed ManagedPropertys that can be applied to the deployment attachment attribute by navigating from the attachment root to the correct attachment property. For now I'm going to create a fake datasource deployer to allow all of the profile service usecases to be fleshed out to finalize the apis. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000718#4000718 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000718

19 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1259 - element ref and type qnames

by jason.greene＠jboss.com

Yes, you are correct, that's how it should be. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000712#4000712 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000712

19 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Design of wsimport

by jason.greene＠jboss.com

I thought I would outline the plan for the JAX-WS wsdl->java tool (wsimport). API Dependencies Unlike the java to wsdl processing, wsimport is more isolated and has minimal API requirements from core: | * WSDLDefinitions - Our WSDL API is the main source, as this tool largely has 1 input, the WSDL file. | * JAXB XJC API - This will be needed to generate Java types for all schema types contained in the WSDL. | * JAXB Code Model API - Since the XJC API returns instances of JCodeModel, we might as well use it for generating the remaining Java artifacts. | * JDK Compiler or Javassist - We will either need to invoke the JDK compiler or build a JCodeModel to bytecode translator using javassit | Key Tasks The following are the major tasks for implementing this tool: | * Enhance WSDLDefinitions - The WSDLDefinitions API needs to be enhanced to handle the custom jaxws binding extension elements. Also WSDL11Reader needs to be enhanced to take a DOM view of all schema elements and make them available as a DOMTypes object (already exists for generation now). | * Implement Binding File Processing - A JAX-WS binding file parser needs to be implemented. This binding file allows you to specify customizations that apply to the WSDL file, but without having to modify the WSDL file. | * WSDL XPath Modifcation Phase - Since the binding file uses xpath expressions, we must first read the WSDL file into a DOM tree, then perform the XPath modifications to obtain the inlined version. After this the WSDL11Reader will produce a WSDLDefinitions model that contains the additional JAX-WS metadata. | * Implement Core Processing Engine - This component will be responsible for interpreting the resulting metadata, and generating artifacts through JAXB XJC and the JAXB Code Model API that conform to the WSDL to Java portion of the specification. | * Implement Source and Bytecode generation - At the end of the processing phase, bytecode and optionally source will need to be written to disk. The code model API has the capability to generate the source; however, it has no direct bytecode generation capability. This would have to be implemented by us, or we could just invoke the compiler and delete the source files if they aren't desired by the user. | * API - A simple API will need to be developed that takes the input options, and returns the list of artifacts generated, as well as any error or warning conditions that occurred. | * Command line tool - This will be a simple command line tool that uses the above API to perform the required processing. | * ANT Task - A simple ant task that offers the same options needs to be developed. As in the command line tool, it should use the above API. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000708#4000708 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000708

19 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Plan to improve CMS integration

by roy.russo＠jboss.com

Does this mean that the CMSPortletWindow can now display in pages other than default.default? Can we get this done without modifying the -object.xml... or at least make it so its backward compatible? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000686#4000686 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000686

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: What does this mean?

by scott.stark＠jboss.org

Its the SecurityDeployer having a write-only ignoreSuffixes property: AbstractBeanMetaData@7ba65cf7{name=SecurityDeployer bean=org.jboss.deployment.security.SecurityDeployer properties=[ignoreSuffixes] constructor=null installs=[MainDeployer.addDeployer] uninstalls=[MainDeployer.removeDeployer]} ... AbstractPropertyInfo@1943b93b{name=ignoreSuffixes getter=null setter=ReflectMethodInfoImpl@2b5d7e8e{name=setIgnoreSuffixes[ParameterizedClassInfo(a)71fb2e0{java.util.HashSet<java.lang.String>}] return=void}} The problem occurs at the Configurator.getPropertyGetterJoinPoint | 18:49:29,115 WARN [AbstractSetMetaData] Exception in preinstantiated lookup: | java.lang.NullPointerException | at org.jboss.kernel.plugins.config.Configurator.getPropertyGetterJoinPoint(Configurator.java:381) | at org.jboss.kernel.plugins.config.Configurator.getPropertyGetterJoinPoint(Configurator.java:360) | at org.jboss.kernel.plugins.config.AbstractKernelConfigurator.getPropertyGetterJoinPoint(AbstractKernelConfigurator.java:115) | at org.jboss.beans.metadata.plugins.AbstractTypeMetaData.preinstantiatedLookup(AbstractTypeMetaData.java:150) | at org.jboss.beans.metadata.plugins.AbstractCollectionMetaData.getCollectionInstance(AbstractCollectionMetaData.java:208) | at org.jboss.beans.metadata.plugins.AbstractCollectionMetaData.getValue(AbstractCollectionMetaData.java:85) | at org.jboss.kernel.plugins.config.Configurator.getPropertySetterJoinPoint(Configurator.java:502) | at org.jboss.kernel.plugins.config.Configurator.getPropertySetterJoinPoint(Configurator.java:446) | at org.jboss.kernel.plugins.config.Configurator.getPropertySetterJoinPoints(Configurator.java:410) | at org.jboss.kernel.plugins.config.AbstractKernelConfigurator.getPropertySetterJoinPoints(AbstractKernelConfigurator.java:120) | at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:54) | Either this code or the caller needs to validate that a getter exists. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000681#4000681 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000681

19 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Plan to improve CMS integration

by julien＠jboss.com

I have started the work on that. One neat advantage is the cms window declaration now looks like : | <window> | <window-name>CMSWindow</window-name> | <content-type>cms</content-type> | <region>center</region> | <height>0</height> | <uri>/default/index.html</uri> | </window> | My first idea on the implementation was to introduce sub interfaces like | interface PortletWindow extends Window { ... } | But it turns out that it does not cope well with hibernate system and does not allow plugability of content very well. Also one of my initial idea is to leverage the generic portal object properties to store the window content type (portlet or cms for now). So finally I chosed to delegate content handling to a WindowContent interface which has sub interfaces. | public interface Window extends PortalObject | { | ContentType getContentType(); | WindowContent getContent(); | } | | public interface WindowContent | { | } | | public interface PortletContent extends WindowContent | { | String getInstanceRef(); | void setInstanceRef(String instanceRef); | } | | public interface CMSContent extends WindowContent | { | String getURI(); | void setURI(String uri); | } | The plug is done in the impl package which supports content handler that are responsible to create the WindowContent interfaces. The portal object container uses that to create the right WindowContent impl when it retrieves objects from the database. At runtime now, I have extended the RenderWindowCommand in order to handle the different content types differently. The portlet one, is mostly like the current one. The cms one extends the portlet one and changes several things : 1/ always retrieve the CMSPortletInstance instance | InstanceContainer container = getControllerContext().getController().getInstanceContainer(); | return container.getDefinition("CMSPortletInstance"); | 2/ if no navigational state exists, create it and initialize it with the URI provided by the CMSContent interface | // | CMSContent content = (CMSContent)window.getContent(); | String uri = content.getURI(); | | // Initialize the navigational state with the URI when needed | PortletParametersStateString navigationalState = (PortletParametersStateString)getAttribute(NAVIGATIONAL_STATE_SCOPE, windowId); | if (navigationalState == null) | { | navigationalState = new PortletParametersStateString(); | navigationalState.setValue("path", uri); | setAttribute(NAVIGATIONAL_STATE_SCOPE, windowId, navigationalState); | } | 3/ modify the results in order to add the properties that force no decoration of the window | if (o instanceof WindowResult) | { | WindowResult result = (WindowResult)o; | | // | Map props = new HashMap(result.getWindowProperties()); | props.put("theme.windowRendererId", "emptyRenderer"); | props.put("theme.decorationRendererId", "emptyRenderer"); | props.put("theme.portletRendererId", "emptyRenderer"); | | // | result.setWindowProperties(props); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000678#4000678 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000678

19 years, 2 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 January 2007