[Design of OSGi Integration] - Facade Questions
by alesj
Moving this to the forum:
"johnbailey" wrote :
| I am still trying to get a grasp of how the Facade will be used.
| After the forum post, I think I understand the bundles will be loaded
| into the MC like any other deployment, but will have meta-data taken
| from the manifest to drive some of the wiring for classloading. I
| like the idea that a Bundle facade can reference any deployment
| regardless of whether it came from an OSGI bundle from the start. So
| that being said, who will be referencing the Bundles? I can see how
| the BundleActivator deployer creates the BundleContext, which creates
| the BundleImpl. The BundleContext is created with a DeploymentUnit,
| which has an attachment of the DeploymentControllerContext, correct?
| From Adrian's comments, it seems the Bundle is a Facade over the
| DeploymentControllerContext. So if Bundle.start is called, it would
| actually change the state of the ControllerContex, but who would ever
| do this?
|
| I have created some tests that use a JarStructure deployer and the
| OSGI Manifest and BundleActivator to deploy an OSGI based JAR. The MC
| will deploy the JAR and the BundleActivator as well as invoking the
| start start opperation on the BundleActivator. I can see how this
| will allow the BundleActivator to register services into the MC using
| the BundleContext, but in this process the Bundle isn't used, which
| makes sense as the Bundle is just a Deployment to the MC with
| additional wiring constraints. So why would I get access to the
| Bundle? If so it just seems like I would get the ControllerContext
| and create the Bundle from there?
|
| Am I making any sense? I am getting a really good understanding of
| the MC and deployments, but I guess I need a clearer understanding of
| how a client would use the Facade? Is there a client type we are
| looking to support?
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131282#4131282
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131282
18 years, 1 month
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Implementing JAXB style parsing for aop-mc-int
by kabir.khan＠jboss.com
I seem to need more in my AOPDeployment, the following works for both
| <aop xmlns="urn:jboss:aop-beans:1.0">
| <aspect class="org.jboss.test.microcontainer.beans.TestAspect"/>
| </aop>
|
and
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
| <aspect xmlns="urn:jboss:aop-beans:1.0" class="org.jboss.test.microcontainer.beans.TestAspect"/>
| </deployment>
|
| private TestSchemaResolver setupResolver()
| {
| TestSchemaResolver resolver = new TestSchemaResolver();
|
| SchemaBinding binding = addSchemaBinding(resolver, AbstractKernelDeployment.class);
| binding = addSchemaBinding(resolver, AOPDeployment.class);
| binding = addSchemaBinding(resolver, JavaBean.class);
|
| return resolver;
| }
|
And I need to add the aspect stuff to AOPDeployment. If "aspects" is not listed in the propOrder it does not get picked up
| @ManagementObject(properties = ManagementProperties.EXPLICIT) // TODO - explicitly add props we want to manage
| @JBossXmlSchema(namespace="urn:jboss:aop-beans:1.0", elementFormDefault=XmlNsForm.QUALIFIED)
| @XmlRootElement(name="aop")
| @XmlType(propOrder={"annotations", "classLoader", "beanFactories", "create", "start", "stop", "destroy", "aliases", "aspects"})
| public class AOPDeployment extends AbstractKernelDeployment
| {
| private static final long serialVersionUID = 1L;
|
| List<AspectBeanMetaDataFactory> aspects;
|
| public List<BeanMetaDataFactory> getBeanFactories()
| {
| return beanFactories;
| }
|
| public List<AspectBeanMetaDataFactory> getAspects()
| {
| return aspects;
| }
|
| @XmlElement(name="aspect")
| public void setAspects(List<AspectBeanMetaDataFactory> aspects)
| {
| this.aspects = aspects;
| }
|
| @Override
| public List<BeanMetaData> getBeans()
| {
| List<BeanMetaData> allBeans = super.getBeans();
| if (allBeans == null)
| {
| allBeans = new ArrayList<BeanMetaData>();
| }
|
| for (AspectBeanMetaDataFactory aspect : aspects)
| {
| allBeans.addAll(aspect.getBeans());
| }
|
| if (allBeans.size() == 0)
| {
| return null;
| }
| return allBeans;
| }
|
| }
|
|
Does this look like the correct approach?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131227#4131227
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131227
18 years, 1 month
[Design of JBoss Portal] - Re: future directions
by sohil.shah＠jboss.com
anonymous wrote :
| If you say so but to my understanding PF is a protocol to refresh portlets without refreshing the entire page. What bothers me is not PF it is the apparent lack of concept for layout, perhaps it is only a lack of explanation.
|
Presentation Framework is a work in progress even at the concept/design level. Besides providing smart aggreation/partial refresh/otb ajax client, it will deal with the concept of Layout Management and Theme Management
Now the specifics of features/functions to be supported by the Layout Management piece is still on the drawing board and we can definitely draw from the ideas being projected by you/community.
I will start a Design Discussion on the LayoutManagement piece once we are ready to start on the component of the Presentation Framework.
Currently, our focus is on getting the Aggregation piece/other integrations in order.
Hope this is helpful information
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131206#4131206
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131206
18 years, 1 month
[Design of POJO Server] - Re: syntax for specifying dependencies?
by alesj
Check org.jboss.web.deployers.AbstractWarDeployer for the mbean Adrian mentioned.
| protected void deployWebModule(VFSDeploymentUnit unit, JBossWebMetaData metaData,
| AbstractWarDeployment deployment)
| throws Exception
| {
| log.debug("deployWebModule: " + unit.getName());
| try
| {
| ServiceMetaData webModule = new ServiceMetaData();
| String name = getObjectName(metaData);
| ObjectName objectName = new ObjectName(name);
| webModule.setObjectName(objectName);
| webModule.setCode(WebModule.class.getName());
| // WebModule(DeploymentUnit, AbstractWarDeployer, AbstractWarDeployment)
| ServiceConstructorMetaData constructor = new ServiceConstructorMetaData();
| constructor.setSignature(new String[] { VFSDeploymentUnit.class.getName(),
| AbstractWarDeployer.class.getName(), AbstractWarDeployment.class.getName()});
| constructor.setParameters(new Object[] {unit, this, deployment});
| webModule.setConstructor(constructor);
|
| // Dependencies...Still have old jmx names here
| Collection<String> depends = metaData.getDepends();
| List<ServiceDependencyMetaData> dependencies = new ArrayList<ServiceDependencyMetaData>();
| if (depends != null && depends.isEmpty() == false)
| {
| if (log.isTraceEnabled())
| log.trace(name + " has dependencies: " + depends);
|
| for(String iDependOn : depends)
| {
| ServiceDependencyMetaData sdmd = new ServiceDependencyMetaData();
| sdmd.setIDependOn(iDependOn);
| dependencies.add(sdmd);
| }
| }
| webModule.setDependencies(dependencies);
|
| // Here's where a bit of magic happens. By attaching the ServiceMetaData
| // to the deployment, we now make the deployment "relevant" to
| // deployers that use ServiceMetaData as an input (e.g. the
| // org.jboss.system.deployers.ServiceDeployer). Those deployers
| // can now take over deploying the web module.
|
| // TODO could create multiple components for the deployment
| // The ServiceConstructorMetaData is not serializable due to its args
| unit.addAttachment(ServiceMetaData.class, webModule);
| }
| catch (Exception e)
| {
| throw DeploymentException.rethrowAsDeploymentException("Error creating rar deployment " + unit.getName(), e);
| }
| }
|
| /**
| * Get the object name of the ServiceMetaData instance associated with
| * the WebMetaData. This uses the pattern:
| * "jboss.web.deployment:war="+metaData.getContextRoot()
| *
| * @param metaData - the web app metaData
| * @return "jboss.web.deployment:war="+metaData.getContextRoot();
| */
| protected String getObjectName(JBossWebMetaData metaData)
| {
| String ctxPath = metaData.getContextRoot();
| // The ctx path value cannot be empty in the object name
| if( ctxPath == null || ctxPath.length() == 0 )
| ctxPath = "/";
| String objectName = "jboss.web.deployment:war="+ctxPath;
| return objectName;
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131200#4131200
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131200
18 years, 1 month