April 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: schema for mail template and activity

by alex.guizar＠jboss.com

Examples cannot be produced at this point because the syntax and the design have not been agreed upon. Unlike other activities email has more complex setup and more moving parts. Let us focus on making the design decisions first. There are two concepts in play. * mail template describes the contents of an email * mail producer takes a template as input and produces a template as output In Brad's current model, the above concepts are treated as two parts of the same thing. The mail activity configuration is read into the fields of the mail producer, and the produce(Execution) method reads those fields to create an email. public interface MailProducer { | Email produce(Execution); | } In my alternate proposal, the template is a separate entity object that represents the configuration. The template is passed to the producer to create an email. The producer thus becomes a control object: it appears to be stateless from the outside. public interface MailProducer { | Email produce(Execution, MailTemplate); | } In my current conception, MailTemplate is a concrete class, as emails have a standard-defined structure. The extension points are narrowed to the producer itself. As soon as we decide on a design, we can jump to work out examples. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225770#4225770 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225770

16 years, 11 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: Applying persisted changes.

by scott.stark＠jboss.org

"emuckenhuber" wrote : | Hmm well we are applying the information in PRE_REAL. As the messaging-beans are also in deploy/ they are most probably in the same state - so not installed. This will be a general problem with extensions that are added via injection, install callbacks, etc. The fully populated managed objects can only be done on a fully initialized kernel. If extensions are beans themselves, the managed object creation cannot even be done correctly as part of the deployment processing. This does require that extensions be installed as part of the deployers bootstrap phase. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225740#4225740 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225740

16 years, 11 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: Applying persisted changes.

by emuckenhuber

"scott.stark(a)jboss.org" wrote : | I don't see this if I run the JmsDestinationRestartUnitTestCase after the JmsDestinationOverrideTestCase when the server is running. The JmsDestinationRestartUnitTestCase.testQueueTemplate fails if I run the JmsDestinationOverrideTestCase and then restart the server, so we are loading something too early it seems. | Yes the RestartUnitTestCases need a server restart. That's basically where this problem occurs. "scott.stark(a)jboss.org" wrote : | In general both the mbean and MODefinitions would only be visible to the class loader of the deployment, so needing these classes visible when the deployers first load is not correct. We don't processes any persisted attachments unless we see a deployment with a matching attachments, so it could just be that this is an implicit dependency issue where the destinations-service.xml is getting processed before the messaging-jboss-beans.xml during startup. | Hmm well we are applying the information in PRE_REAL. As the messaging-beans are also in deploy/ they are most probably in the same state - so not installed. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225726#4225726 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225726

16 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Revisiting versioning for components

by jaikiran

Thinking a bit more, how about something like this: * Affects version will refer to distribution versions (like as-int, plugin, embedded) [1] * Fix version will refer to distribution versions (like as-int, plugin, embedded) * Component Affects Version - If some field like this could be made available, then we could use this to refer to each component's version. This field would in most of the cases be set by us and not usually by end users reporting the issue * Component Fix version - Refers to the component version [1] Still how do we distinguish 1.a.b version of as-int from 1.p.q version of plugin. Unless the versioning in JIRA is something like as-int-1.a.b and plugin-1.p.q View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225714#4225714 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225714

16 years, 11 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: Applying persisted changes.

by scott.stark＠jboss.org

"emuckenhuber" wrote : | Looks like the MODefinitions are getting installed too late (as they are in deploy/messaging). | Moving those definitions to deployers/ seems to work, although in the end this should not be needed? | I don't see this if I run the JmsDestinationRestartUnitTestCase after the JmsDestinationOverrideTestCase when the server is running. The JmsDestinationRestartUnitTestCase.testQueueTemplate fails if I run the JmsDestinationOverrideTestCase and then restart the server, so we are loading something too early it seems. In general both the mbean and MODefinitions would only be visible to the class loader of the deployment, so needing these classes visible when the deployers first load is not correct. We don't processes any persisted attachments unless we see a deployment with a matching attachments, so it could just be that this is an implicit dependency issue where the destinations-service.xml is getting processed before the messaging-jboss-beans.xml during startup. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225709#4225709 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225709

16 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Revisiting versioning for components

by jaikiran

I agree, the fix version right now isn't clear enough for tracking issues. anonymous wrote : | Right now 'Fix Version' and 'Affects Version' reflects the version of ejb3-core which we are using. I thought it reflected the version of as-int anonymous wrote : | So at least for the three distributed artifacts I think we should have versions: | 1. as-int | 2. embedded | 3. plugin Any specific reason, we want to limit it to these 3? Maybe because this is the only 3 ways (currently) that we distribute EJB3? anonymous wrote : We now also have the option on using 'Component Fix Version(s)'. So if a issue is reported against the "interceptors" component and fixed in 1.x.y version of the "interceptors" and the "interceptors" 1.x.y version is distributed through "as-int" version 1.a.b and "plugin" version 1.p.q, then we would mark it as: | Component/s: interceptors | Affects Version/s: None (what do we use here? the version of component or the distribution) | Fix Version/s: 1.a.b, 1.p.q (Again how do we distinguish 1.a.b corresponds to as-int and 1.p.q to plugin) | | Component Fix Version(s): 1.x.y (this corresponds to interceptors version) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225708#4225708 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225708

16 years, 11 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: Applying persisted changes.

by scott.stark＠jboss.org

"emuckenhuber" wrote : | I think that will simplify things for the attachment persistence. | Last week i was briefly looking into something similar. It's basically not that obvious, as IMHO parts of what ServiceMetaDataICF and BeanMetaDataICF are doing should be moved out. | On the other hand looking at the connection factory ICFs - those actually only do operations on the ConnectionFactoryMetaData itself, which should be fine. | | So i think that one of the goals should be to have a clearer separation between the metaData operations and the extension behavior. | Although refactoring ICFs totally out of this process could be quite hard. Maybe creating something new but similar for the extension behavior could be easier? | | Leaving the meta data operations in the responsablitly of the ICFs (setValue, getValue). On top of that the extension behavior like overriding the moClass, getting the values from the MBeanServer or the MCBean... Also adding and creating a new attribute to the meta data e.g. ServiceAttributeMD could be done by the extensions. | Is similar to what you have in mind? The ICF behavior needs to be separated out into the type/metadata driven aspect of creating the MO skeleton and subsequent population. The value read access of the ICF is an extension of the current ManagedObjectPopulator default implementation. There is a disconnect between the ManagedDeployment/ManagedComponent and the DeploymentUnit/component DeploymentUnit that is what the KernelDeploymentManagedObjectCreator is essentially working around. In general we need to be doing something like: 1. Create the ManagedObject metadata from attachments and extensions based on metadata 2. Create the ManagedDeployment/ManagedComponent/ManagedObject skeletons. This view should work even without a sever with default values coming from the ManagedProperty metadata 3. Provide a full runtime view with stats, operations via a population step. Getting to this abstraction for 5.1 is not possible. What we can do in the next week is what I'm trying to figure out today. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225706#4225706 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225706

16 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Revisiting versioning for components

by wolfc

We now also have the option on using 'Component Fix Version(s)'. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225679#4225679 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225679

16 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Revisiting versioning for components

by wolfc

Right now 'Fix Version' and 'Affects Version' reflects the version of ejb3-core which we are using. While this is the most accurate reflection of what we currently distribute via as-int, plugin and embedded, it bears no/little relationship to the version of that distribution. Which leads to weird tracking of: https://jira.jboss.org/jira/browse/EJBTHREE-1492 https://jira.jboss.org/jira/browse/EJBTHREE-1803 https://jira.jboss.org/jira/browse/EJBTHREE-1805 So at least for the three distributed artifacts I think we should have versions: 1. as-int 2. embedded 3. plugin This is then reflected and tracked on the road map. Hmm, still we have issues like: https://jira.jboss.org/jira/browse/EJBTHREE-1806 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225665#4225665 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225665

16 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - JUnit Reports...

by clebert.suconic＠jboss.com

hudson-reports is aways generating the JUnitReports, and the report will take some space on hudson in a hourly base, even though the report is never looked (Hudson provides its own reporting). So, I would like to remove the compile-reports call from hudson-reports. I would like to also update junit-frames.xsl with the one provided by ant. The xsl we use is years old and exists since JBoss3. If we get a newer one we will have the System.out report (which I find it useful). Any thoughts or contrary opinions? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225641#4225641 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225641

16 years, 11 months

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 April 2009