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

[Deployers on JBoss (Deployers/JBoss)] - HOWTO deploy webapp dynamically

by thomas.diesler＠jboss.com

Folks, this is related to http://jira.jboss.org/jira/browse/JBWS-1967 I now generate the JBossWebMetaData object in memory and want to deploy it through the main deployer. Previously I used to do | VirtualFile file = VFS.getRoot(warURL); | Deployment deployment = VFSDeploymentFactory.getInstance().createVFSDeployment(file); | MutableAttachments attach = (MutableAttachments)deployment.getPredeterminedManagedObjects(); | attach.addAttachment(WebMetaDataModifier.PROPERTY_GENERATED_WEBAPP, Boolean.TRUE); | | mainDeployer.deploy(deployment); | Please show me how I create a deployment that is not based on a file. I looked at http://labs.jboss.com/file-access/default/members/jbossmc/freezone/docs/2... but that does not give me much information. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131023#4131023 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131023

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Layout: Example of what it really is

by PMN

To discover what a layout really is see the following link: http://developer.yahoo.com/yui/examples/layout/adv_layout_source.html This is only a beta but other ajax dev kit are on the same track. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131014#4131014 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131014

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: future directions

by PMN

The point is that I agree with most parts but there is a missing point : page control... Portlets are not exactly independent from each other, first there are interactions defined by events and second there is a layout in the page, where windows are place holders to display portlet content. The second point is missing in jbp, unless I am mistaken, there is no way (or insufficient) way to change the layout of a page upon event. Anyway, as long as "basic html" is maintained, I am ok. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131003#4131003 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131003

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: ServiceMetaData has the most recent dependencies/attribu

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | In practice, this just shows that the EJB/WEB containers are not | creating their containers correctly and the respective service being | used is not exposed for IOC (or aspect dependency) properly. | | If they were these kind of transitive dependencies; | ejb -> security -> security policy | ejb -> security aspect -> security policy injection into the aspect | would be would be automatic. | Creating a depends-with-optional-attribute is the equivalent ioc we supported with the mbean model. This requires adding a ServiceAttributeMetaData with a ServiceDependencyValueMetaData value. We still end up modifying the ServiceMetaData. The ServiceMetaData is an implementation detail of the ejb container as its the JBossMetaData that would have the management interface. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130964#4130964 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130964

18 years, 1 month

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Duplicate mbean removal

by ron.sigal＠jboss.com

The problem is related to the use of 0.0.0.0 as a bind address. See JIRA issue JBREM-909 "Connector.stop() cannot find invoker MBean when bind address is 0.0.0.0" (http://jira.jboss.com/jira/browse/JBREM-909). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130958#4130958 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130958

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: future directions

by julien＠jboss.com

"PMN" wrote : ok, then it is like other "solution oriented" features, the only advanced feature is to choose among 4 approaches without defining concepts. Today the UI presentation for a portal is a technology which is volatile (not so much). Yesterday it was classic HTML, today it is also Ajax, and tomorrow what will it be ? So should I rewrite the whole portal when a new client technology becomes mainstream on the market ? This is what PF is about. Beside isolating the core portal from the UI layer is to ensure that the client state (whether it is HTML, Ajax, etc...) is always correct. Consider this scenario: 1/ you interact with portlet A (process action) 2/ A update its render parameters and fire an event 3/ Portal decides to deliver event to portlet B on same page 4/ portlet B update its render parameters upon event 5/ meanwhile portlet C also on the same page as its cached markup that has just expired (so it is stale) after this serie of interaction, what the client needs to see is the update of the markup of portlet A, B and C, whatever the client UI technology is. in case of "Classic" nothing needs to do as we compute the page on each refresh in case of "Ajax", the client layer impl needs to detect that the 3 windows on the screen are stale and replace them during the single interaction. Do you consider that as: 1/ a commodity that you would expect from an enterprise class portal 2/ an advanced feature 3/ 1 + 2 This is also what PF is about. "PMN" wrote : The layout - currently provided with a jsp and renderer - is defined at page level not portlet level and that 's the point. Flex is easily embedded in ajax and ajax is only an extension of "html classic", ajax is beyond the portal logic, your approach is not clear or flaked. Can you explain more what you mean ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130934#4130934 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130934

18 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: COM Gateway

by kurt.stam＠jboss.com

1. A COM gateway would listen for COM events. We use Notifiers to send messages out of the ESB (not listeners). So you'd want to make a COM Notifyer too if I understand your drawings right. 2. I think both Mark and I are assuming you want to talk COM out of performance reasons. Is that right? I would be easier to go across something like WebServices. 3. Maybe you can elaborate a bit more on what it is you want to use this for? --Kurt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130930#4130930 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130930

18 years, 1 month

1
0
0 / 0

[Design of Security on JBoss] - PolicyConfiguration commit and linkConfiguration API

by anil.saldhana＠jboss.com

Redoing the security deployers, I came across this thing which I had not given a lot of thought before. * You can link a child PolicyConfiguration to a parent only if it is not committed (or inService). * A commit on the parent policyConfiguration does not commit the children. I looked at the API javadocs as well as in the spec. There is no cascaded commit. So basically you have to link the child PC and then commit it. The ParentPC commit can happen irrespective of whether the linked PCs are committed (ie. inService or not). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130925#4130925 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130925

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: ServiceMetaData has the most recent dependencies/attribu

by anil.saldhana＠jboss.com

This week I have rewritten the Security Deployer (or more precisely to split into deployers based on the type of metadata). It is ready and I am checking it in tomorrow. The classes look as follows: | public abstract class AbstractSecurityDeployer<T extends IdMetaData> | extends AbstractDeployer | { | public AbstractSecurityDeployer() | { | setStage(DeploymentStages.POST_CLASSLOADER); | ... | setOutput(ServiceMetaData.class); | ... | } | } | | public class EarSecurityDeployer extends AbstractSecurityDeployer<JBossAppMetaData> | { | } | | public class EjbSecurityDeployer | extends AbstractSecurityDeployer<JBossMetaData> | {} | | public class WarSecurityDeployer extends AbstractSecurityDeployer<JBossWebMetaData> | { } | An issue that exists for addDependencies/addAttributes api addition to ServiceMetaData is that the internal data structures are Lists (rather than Sets) and hence there can be duplication of dependencies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130920#4130920 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130920

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Breaking up jboss.microcontainer.lib

by scott.stark＠jboss.org

Ok. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130917#4130917 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130917

18 years, 1 month

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 February 2008