[Design of JBoss jBPM] - GPD New Generation Extensibility
by koen.aers@jboss.com
anonymous wrote : Hi Koen,
|
| Am trying to do it on my own - am running into an issue with the JpdlLabelProvider. The list of icons and labels is hard-coded in here - are you planning to expose these via additional elements/attributes on the "core" and "ui" element extensions?
|
| thanks,
| Mohan
|
Hi Mohan,
Nice to see that you are investigating the GPD code. Please don't hesitate to use this forum to ask questions and generate feedback if you think things can be improved.
As for your question, the new generation of the GPD is not yet ready for custom extensions. As you correctly have observed, not all the necessary information can be specified in the available extension points. In some places (such as the label provider and the editpart factories) big switch/case logic is present to select the right icon or figure. Also the editpolicies can not yet be specified in the plugin.xml. Well, to be more correct, the extensions are not used at the moment.
These capabilities (custom extensions of the GPD) will certainly *not* make it into the 3.1.0 GA release because of time constraints. They will be however most certainly be part of a future release in the 3.1.x branch. I know the answer is probably disappointing. However, if you really want to do a custom extension right now, you can identify the places where the switch/cases are found, and replace those classes with your own implementation.
Best regards,
Koen
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4013870#4013870
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4013870
19 years, 2 months
[Design of JBoss Build System] - Legacy (1.0.x) jboss common maven2 repo location
by scott.stark@jboss.org
I can tell what if any of the current repository.jboss.com/maven2 contents are valid jboss-common 1.0.x releases. Only common/core/jboss-common-core/1.0 has any meaningful content:
| [starksm@succubus jboss]$ pwd
| /usr/Repository/repository.jboss.com/maven2/jboss
| [starksm@succubus jboss]$ ls -R common/
| common/:
| 4.0.4/ core/ CVS/
|
| common/4.0.4:
| CVS/
|
| common/4.0.4/CVS:
| Entries Repository Root
|
| common/core:
| CVS/ jboss-common-core/
|
| common/core/CVS:
| Entries Repository Root
|
| common/core/jboss-common-core:
| 1.0/ 1.0.1.TEST/ 1.0.2/ CVS/
|
| common/core/jboss-common-core/1.0:
| CVS/ jboss-common-core-1.0.pom
| jboss-common-core-1.0.jar jboss-common-core-1.0-sources.jar
|
| common/core/jboss-common-core/1.0/CVS:
| Entries Repository Root
|
| common/core/jboss-common-core/1.0.1.TEST:
| CVS/
|
| common/core/jboss-common-core/1.0.1.TEST/CVS:
| Entries Repository Root
|
| common/core/jboss-common-core/1.0.2:
| CVS/
|
| common/core/jboss-common-core/1.0.2/CVS:
| Entries Repository Root
|
| common/core/jboss-common-core/CVS:
| Entries Repository Root
|
| common/CVS:
| Entries Repository Root
|
| [starksm@succubus jboss]$ ls -R core
| core:
| common-core/ CVS/
|
| core/common-core:
| 1.0.0.GA/ CVS/
|
| core/common-core/1.0.0.GA:
| CVS/
|
| core/common-core/1.0.0.GA/CVS:
| Entries Repository Root
|
| core/common-core/CVS:
| Entries Repository Root
|
| core/CVS:
| Entries Repository Root
|
There looks to be a 2.0.3.GA and 4.0.4 release under jboss/jboss-common as well:
| [starksm@succubus jboss]$ ls -R jboss-common
| jboss-common:
| 2.0.3.GA/ CVS/ maven-metadata.xml
| 2.0.4.Alpha/ maven-metadata-cvs-file-repository.xml maven-metadata.xml.md5
| 4.0.4/ maven-metadata-local.xml maven-metadata.xml.sha1
|
| jboss-common/2.0.3.GA:
| jboss-common-2.0.3.GA.pom jboss-common-2.0.3.GA.pom.sha1
| jboss-common-2.0.3.GA.pom.md5
|
| jboss-common/2.0.4.Alpha:
| jboss-common-2.0.4.Alpha.pom
|
| jboss-common/4.0.4:
| CVS/ jboss-common-4.0.4.jar jboss-common-4.0.4.pom
|
| jboss-common/4.0.4/CVS:
| Entries Repository Root
|
| jboss-common/CVS:
| Entries Repository Root
|
The jboss/jboss-common/2.0.3.GA/ was prior to changing the common-core artifactId to jboss-common-core. I'm going to delete these common and core directories, the jboss/jboss-common/2.0.3.GA/, and add the repository.jboss.com/jboss/common/1.0.3.GA under repository.jboss.com/jboss/jboss-common/1.0.3.GA to try to straighten out the legacy jboss-common repository artifacts.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4013840#4013840
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4013840
19 years, 2 months
[Design the new POJO MicroContainer] - Re: Scoped beans deployment
by adrian@jboss.org
"alesj" wrote : "adrian(a)jboss.org" wrote :
| | So this means that Bindings should be deployed against new (Scoped)Kernel, not against the underlying.
|
| The bindings are done against the MutableMetaData which is a shared
| repository. It already has a notion of scope.
|
| The scoped kernel is a different feature.
| That is where you would do something like:
|
|
| | <deployment>
| | <annotation>@org.jboss.metadata.plugins.scope.DeploymentScope</annotation>
| | </deployment>
| |
|
| This would:
|
| Stages (1) and (2) are optional if they already exist
|
| 1) Create a MutableMetaData for this scope
| 2) Create a kernel (or maybe just a kernel controller) for this scope and add it to
| the MutableMetaData, the kernel's parent would come from any kernel in the
| parent's scope or the default kernel if there is no such thing
| 3) Deploy the bean(s) into that scoped kernel
|
| You should also support things like:
|
| | <deployment>
| | <bean>
| | <annotation>@org.jboss.metadata.plugins.scope.SubsystemScope("jca")</annotation>
| | </bean>
| | </deployment>
| |
|
| In both cases, you pick out all the "scope" annotations.
|
| Iincluding those that are on the bean class if they are not overridden.
| The MetaData (read only context) already has the processing to do this
| since each instance scope has a parent scope of the class.
|
| For ease of use (less boiler plate) I've also previously suggested or would suggest:
|
| 1) The qualifier for @org.jboss.metadata.plugins.scope.DeploymentScope
| should come from KernelDeployment.getName() if the user doesn't specify it.
| 2) Support simple scoping definitions directly in the xml, e.g.
|
| | <deployment scoped="true">
| |
| The latter being the same as just adding the DeploymentScope annotation
| to the deployment.
|
| NOTE: We don't have any processing at the moment that lets you add
| annotations at the deployment level. This is obviously a useful feature
| where you want all beans to have the same annotations, like the scope.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4013761#4013761
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4013761
19 years, 2 months
[Design the new POJO MicroContainer] - Re: Scoped beans deployment
by alesj
"adrian(a)jboss.org" wrote :
| The policy xml should be unmarshalled to an object that implements
| BeanMetaDataFactory. When the deployment invokes getBeans()
| that object will create some BeanMetaData for a POJO
| that knows how to install/uninstall data into the MetaData repository.
|
|
| | public class MetaDataRepositoryInstaller
| | {
| | public void setScope(ScopeMetaData);
| |
| | @Inject // If we can assume there be will only one instance?
| | public void setKernelMetaDataRepository(KernelMetaDataRepository)
| |
| | // The MC will resolve the ValueMetaData to objects!
| | public void setMappings(Map<String, Object>)
| |
| | public void start()
| | {
| | // Install
| | }
| |
| | public void stop()
| | {
| | // Uninstall
| | }
| | }
| |
|
You probably meant this code:
| // Get a link to the scoped metadata
| KernelMetaDataRepository kmdr = kernel.getMetaDataRepository();
| MutableMetaDataRepository mmdr = kmdr.getMutableMetaDataRepository();
| ScopeKey scope = from the <scope/>;
| MutableMetaData mmd = (MutableMetaData) mmdr.getMetaDataRetrieval(scope);
|
| // Not found create it
| if (mmd != null)
| {
| mmd = ...;
| mmdr.addMetaDataRetrieval(mmd);
| }
|
| for (iterate)
| mmd.addMetaData(name, object, object.getClass());
|
into MetaDataRepositoryInstaller.start()?
So this means that Bindings should be deployed against new (Scoped)Kernel, not against the underlying.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4013741#4013741
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4013741
19 years, 2 months