[Design the new POJO MicroContainer] - Re: How to reliably determine if BeanMetaData contains depen
by kabir.khan@jboss.com
https://jira.jboss.org/jira/browse/JBMICROCONT-407
After talking to Ales I have come up with a new version of the visitor
| private boolean hasInjectedBeans(BeanMetaData beanMetaData)
| {
| DependencyMetaDataVisitor visitor = new DependencyMetaDataVisitor(beanMetaData);
| List<ValueMetaData> dependencies = visitor.getDependencies();
|
| for (ValueMetaData dep : dependencies)
| {
| //Ignore the dependencies from the kernel objects
| if(!((String)dep.getUnderlyingValue()).startsWith("jboss.kernel:service="))
| {
| return true;
| }
| }
| return false;
| }
|
| private static class DependencyMetaDataVisitor extends JBossObject implements MetaDataVisitor
| {
| MetaDataVisitorNode node;
| List<ValueMetaData> dependencies = new ArrayList<ValueMetaData>();
| protected Stack<MetaDataVisitorNode> visitorNodeStack = new Stack<MetaDataVisitorNode>();
|
| public DependencyMetaDataVisitor(MetaDataVisitorNode node)
| {
| this.node = node;
| describeVisit(node);
| }
|
| public List<ValueMetaData> getDependencies()
| {
| return dependencies;
| }
|
| public void addDependency(DependencyItem dependency)
| {
| }
|
| public <T> void addInstallCallback(CallbackItem<T> callback)
| {
| }
|
| public <T> void addUninstallCallback(CallbackItem<T> callback)
| {
| }
|
| public ControllerState getContextState()
| {
| return null;
| }
|
| public KernelControllerContext getControllerContext()
| {
| return null;
| }
|
| public void initialVisit(MetaDataVisitorNode node)
| {
| throw new NotImplementedException("Not implemented");
| }
|
| public void describeVisit(MetaDataVisitorNode node)
| {
| visitorNodeStack.push(node);
| try
| {
| internalDescribeVisit(node);
| }
| finally
| {
| visitorNodeStack.pop();
| }
| }
|
| private void internalDescribeVisit(MetaDataVisitorNode node)
| {
| if (node instanceof AbstractDependencyValueMetaData)
| {
| dependencies.add((AbstractDependencyValueMetaData)node);
| }
| Iterator<? extends MetaDataVisitorNode> children = node.getChildren();
| if (children != null)
| {
| while (children.hasNext())
| {
| MetaDataVisitorNode child = children.next();
| child.describeVisit(this);
| }
| }
| }
|
| public void setContextState(ControllerState contextState)
| {
| }
|
| public Stack<MetaDataVisitorNode> visitorNodeStack()
| {
| return visitorNodeStack;
| }
|
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209007#4209007
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209007
15 years, 8 months
[QA of JBoss Portal] - Regarding 'Drag and Drop' -- 'Dashboard' calling 'template'
by Sudarshan Vadyar
Drag and Drop feature for custom portal-pages:
By default drag and drop is enabled in 'Dashboard'. Usually, dashboard can be directly accessed after login, after the respective setting done in 'jboss-portal.sar\conf\config.xml' file.
Usually when dashboard is accessed for the first time, it copies and displays the 'template' portal by default. This is done in 'CustomizationManagerService.java'.
If a solution is provided to make dashboard access the custom deployed , then the drag and drop is available to that portal when the dashboard is accessed directly after login.
A suggestion for the same is:
In 'CustomizationManagerService.java', the following is defined.
private static final PortalObjectId TEMPLATE_ID = PortalObjectId.parse("/template", PortalObjectPath.CANONICAL_FORMAT);
Can this be made more generic, so that the first argument "/template" is a string that can be set to the custom deployed from outside ?
Also, inside the 'getDashboard()' method, a check can be made to find whether the custom deployed is available or not, and if not , dashboard can copy the existing 'template' portal itself.
Alternately, custom portal developers can be provided with some interfacing through which this can be accomplished.
Please let know whether this suggestion is valid and okay.
I remain,
Sudarshan V
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208994#4208994
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208994
15 years, 8 months
[Design of JBoss jBPM] - email templates
by tom.baeyens@jboss.com
imo the first direction to search for the solution is a separate, dummy SEAM web app that is only used for our email templating. maybe that webapp could be secured to only allow access from localhost...
other opinions on email templating ?
below the response from pete muir when i asked him if it was possible to run seam email templating without JSF. the answer was no.
anonymous wrote : > Yeah, you need JSF and Facelets for Seam mail.
| >
| > I was working on having it so Seam mail would be able to use JSF even if
| > it wasn't running in an application server (i.e. Seam mail would boot
| > JSF itself), but this never got 100% finished.
| >
| > On 10 Feb 2009, at 13:11, Tom Baeyens wrote:
| >
| >> Hi Pete,
| >>
| >> Since MailFacesContextImpl extends DelegatingFacesContext, i assume
| >> that seam leverages the delegate faces context from the jsf
| >> implementation and hence it can only run inside a JSF application,
| >> right ?
| >>
| >> Or is it also possible with the seam-mail classes to generate mails in
| >> a standalone java app ?
| >>
| >> --
| >> regards, tom.
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208991#4208991
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208991
15 years, 8 months