[Design of JBoss Portal] - Re: future directions
by PMN
Thanks Thomas, I will try that.
If I can change layout then I can have a workaround to changing region by changing the layout to one of the few layouts I need. Once I have this ability I can use region renderer and other renderers adequately. I will go back to this whenever I have time to redesign my app.
For example, if EDIT mode is used to configure and customize the VIEW mode, in most cases the layout is different.
Layout is really key. Let me try to explain how jbp misses it.
First you can see a grid as a vertical division. Each column have lines and each line in a column can embed a grid as well. Each can be resizeable and with a very simple scheme, column could be resizeable horizontally (changing their width), line vertically (changing their height). In addition of resizing there is also collapse effect with a variant providing vertical accordion or horizontal accordion.
YUI is perfect with grid and resize for layout/region/window, their beta implementation of layout is strange and does not fit well (not the concept just the implementation)
Hope this helps, I 'll revisit my design in a few months. You seem to develop faster than I do anyway.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131991#4131991
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131991
18 years, 1 month
[Design of OSGi Integration] - Re: Facade Questions
by alesj
"johnbailey" wrote :
| On another note, if we are going to support using the facade for any deployment even ones not originating in a OSGI Bundle, we can not assume the OSGIMetaData will be attached to the DeploymentContext. In this case, we will need to create the headers given the other MetaData available, correct?
|
First, OSGIMetaData should only be used for a Describe phase, to construct matching ClassLoaderMetaData.
And CLMD can be attached from where ever; jboss-classloading.xml, programmatically, ...
Or why do you think we need OMD?
If you mean the services that can be used inside particular bundle, via ServiceRegistry, that's shouldn't be a problem.
MC already has a contextual awareness.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131965#4131965
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131965
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
That makes more sense now. But I am getting the following error for the following xml
| <?xml version="1.0" encoding="UTF-8"?>
|
| <aop xmlns="urn:jboss:aop-beans:1.0">
|
| <bean xmlns="urn:jboss:bean-deployer:2.0" name="AspectManager" class="org.jboss.aop.AspectManager">
| <constructor xmlns="urn:jboss:bean-deployer:2.0" factoryClass="org.jboss.aop.AspectManager" factoryMethod="instance"/>
| </bean>
|
| <aspect class="org.jboss.test.microcontainer.beans.TestAspect">
| </aspect>
|
| ...
| </aop>
|
If I comment out the "constructor" element, it parses, but I want to be able to use stuff from the bean-deployer schema. Error:
| org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/C:/cygwin/home/Kabir/sourcecontrol/microcontainer/aop-mc-int/target/tests-classes/org/jboss/test/microcontainer/beans/test/AspectSimpleJaxbAopTestCase.xml@6,125
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:177)
| at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:139)
| at org.jboss.test.xb.builder.JBossXBTestDelegate.unmarshal(JBossXBTestDelegate.java:122)
| at org.jboss.aop.microcontainer.junit.JAXBDeployer.unmarshal(JAXBDeployer.java:84)
| at org.jboss.aop.microcontainer.junit.JAXBDeployer.deploy(JAXBDeployer.java:127)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:256)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:400)
| at org.jboss.aop.microcontainer.junit.AOPMicrocontainerTestDelegate.deploy(AOPMicrocontainerTestDelegate.java:76)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.setUp(MicrocontainerTestDelegate.java:83)
| at org.jboss.aop.microcontainer.junit.AOPMicrocontainerTestDelegate.setUp(AOPMicrocontainerTestDelegate.java:60)
| at org.jboss.test.AbstractTestSetup.setUp(AbstractTestSetup.java:63)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
| at junit.framework.TestResult.runProtected(TestResult.java:124)
| at junit.extensions.TestSetup.run(TestSetup.java:23)
| at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
| at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
| Caused by: org.jboss.xb.binding.JBossXBRuntimeException: {urn:jboss:bean-deployer:2.0}constructor not found as a child of {urn:jboss:bean-deployer:2.0}bean
| at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:396)
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:407)
| at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
| at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
| at org.apache.xerces.xinclude.XIncludeHandler.emptyElement(Unknown Source)
| at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
| at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
| at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
| at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
| at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
| at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
| at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
| at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:173)
| ... 19 more
|
|
I get the same error if I do
| <?xml version="1.0" encoding="UTF-8"?>
|
| <aop xmlns="urn:jboss:aop-beans:1.0">
|
| <bean xmlns="urn:jboss:bean-deployer:2.0" name="AspectManager" class="org.jboss.aop.AspectManager">
| <constructor factoryClass="org.jboss.aop.AspectManager" factoryMethod="instance"/>
| </bean>
|
| <aspect class="org.jboss.test.microcontainer.beans.TestAspect">
| </aspect>
|
| ...
| </aop>
|
>From my schema, the "aop" element is defined as
| <xsd:element name="aop" type="aopType">
| <xsd:annotation>
| <xsd:documentation>
| <![CDATA[
| A domain
| ]]>
| </xsd:documentation>
| </xsd:annotation>
| </xsd:element>
|
| <xsd:complexType name="aopType">
| <xsd:annotation>
| <xsd:documentation>
| <![CDATA[
| aspects or interceptors
| ]]>
| </xsd:documentation>
| </xsd:annotation>
| <xsd:choice minOccurs="0" maxOccurs="unbounded">
| <xsd:element name="domain" type="domainType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="interceptor" type="aspectOrInterceptorType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="aspect" type="aspectOrInterceptorType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="bind" type="bindType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="stack" type="stackType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="typedef" type="typedefType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="cflow-stack" type="cflowStackType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="dynamic-cflow" type="dynamicCflowStackType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="prepare" type="prepareType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="pointcut" type="pointcutType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="annotation-introduction" type="annotationIntroductionType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="annotation" type="annotationType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="precedence" type="precedenceType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="introduction" type="introductionType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="arrayreplacement" type="arrayreplacementType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:element name="arraybind" type="arraybindType" minOccurs="0" maxOccurs="unbounded"/>
| <xsd:any namespace="##other" processContents="strict" minOccurs="0">
| <xsd:annotation>
| <xsd:documentation>An extension value</xsd:documentation>
| </xsd:annotation>
| </xsd:any>
| </xsd:choice>
| </xsd:complexType>
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131955#4131955
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131955
18 years, 1 month
[Design of JBoss Build System] - Re: JBossAS CR1 build plan
by scott.stark＠jboss.org
Keeping ejb3 in the jbossas project really does not solve anything as far as I can see. Its using a different build system that has to be integrated through either maven repos, jbossbuild repos, or module classpaths. Having it out allows for the developers to do work without breaking the as build. Until they produce an artifact its not impacting jbossas.
The problem of as not having proper spis for the ejb3 dependencies needs to be solved regardless. ejb3 does have a proper dependency graph now. If what it depends on it does not have an spi, then that jbossas project needs to be broken up.
We already have an integration project. If we want to make it a requirement that all ejb3 dependencies are coming from there, fine. I'll post what the ejb3 project dependencies coming from the jbossas project are today.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131953#4131953
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131953
18 years, 1 month
[Design of JBoss Build System] - Re: Moving jbossas to a maven repo for thirdparty
by scott.stark＠jboss.org
"pgier" wrote : Unfortunately the mapping part will be separate from the dependencies, because the mapping will have to be a parameter to the plugin. I can't change the XML for the dependencies in the pom without hacking up and forking the maven code. I'll post an example tomorrow of what it looks like once I get a couple more of the details figured out.
|
Right, I was just reproducing the dependency info in the plugin config to allow the mapping to be clear.
"pgier" wrote :
| I'm going to make this a new mojo (maven plugin class) in the current jboss-deploy plugin because they can share some code for writing component-info files and other stuff. I'm thinking about renaming the plugin to something like jboss-thirdparty plugin, but that's low priority.
|
Remember we really don't need the component-info.xml in the local thirdparty contents as we would not be using the jbossbuild repository mechanism any longer.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131945#4131945
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131945
18 years, 1 month