July 2007 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: JBossAppParsingDeployer issue

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : I don't see how allowing the structural parse to introduce deployment metadata has any affect on a programmatic deployment. | Because the structural deployer is not invoked if I tell it explicitly what the structure of the ear is. It is also not invoked if I add a META-INF/jboss-structure.xml Describing the structure programmatically is just a case of adding the structure metadata equivalent of META-INF/jboss-structure.xml to the deployment. In order: 1) Is there is a predetermined StructureMetadata attachment? 2) Is there a META-INF/jboss-structure.xml 3) Is it an EAR - EARStructure. Only if (1) and (2) fail will the EARStructure get invoked. So in summary you can't assume that a structural deployer will be invoked. It shouldn't do anything other than creating structure (and only then when it is invoked because there isn't an explicit structure). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068902#4068902 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068902

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: JBossAppParsingDeployer issue

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : This is wrong. | | e.g. What if I want to deploy an EAR programatically where I tell it upfront | what the structure and metadata is. | | i.e. it doesn't go through either the structure or the parsing deployer, | it uses the structure and metadata I've told it to use when I did the programmtic | deployment. | Then the deployer processing has to support complete vs incomplete inputs. I can have a complete programmatic specification, or multiple partial sources as is the case where javaee naming conventions along with a jboss-app.xml is used to define the contents of an ear. I don't see how allowing the structural parse to introduce deployment metadata has any affect on a programmatic deployment. "adrian(a)jboss.org" wrote : | I'm I supposed to know to add the transient managed object that represents | the context root to the war context I create manually, or should I expect it to | pick it from the J2eeApplicationMetaData where I defined it? | | The correct solution is to have a seperate deployer that looks | for application level metadata when processing subdeployments. | | In principle there is not just the context-root that can defined at the ear | level, one could also provide things like a default "call-by-value" in jboss-app.xml, etc. | | The creator of the deployment (including the profile service) should not | be expected to know what transient managed objects need to be created. | That is just an implementation detail of one way the deployers can "talk to each other". | Right, there are multiple types of component level data that can be specified at the ear level. There are two level of metadata for the javaee components, ear and component. I don't see how introducing another deployer that maps from J2eeApplicationMetaData to the component specific value is better than having the component deployer look in two places. Something produces the J2eeApplicationMetaData (the EARStructure or another implicit AppParsingDeployer that runs when there is no application.xml, or programmatic definition), and component deployers look to the component level source and then to the ear level if needed. Nothing needs to know what the component level piece of metadata for the context-root is. "adrian(a)jboss.org" wrote : | Also to make this work at all, the transient managed objects would | have to be serialized such that a remote caller can add this information | and the profile service can remember what they were when re-creating the deployment, | this doesn't sound correct to me. A remote caller is passing in the ear and having the structure/regular deployers process it. A profile service impl may only be storing the raw ear with just the META-INF/jboss-app.xml and running through the full deployment processing every time, or it may be saving off all metadata as predetermined overrides. I don't see where there is an intermediate situation where a remote caller is providing transient managed objects. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068856#4068856 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068856

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - how to delete process deifinitons

by amybasu

hi, i want to delete some of the process definitions which are redundant. My task list after logging in has become huge, so want to delete the redundant ones. Is there any way i can delete them from the UI screen. I am trying to delete it from the monitoring screen but unable to delete it. It would be great if somebody could help me out. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068823#4068823 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068823

17 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: FLUSH and state transfer during high invocation load

by manik.surtani＠jboss.com

Changed your patch to use the state transfer timeout rather than the sync repl timeout in waiting for the block gate. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068794#4068794 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068794

17 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: FLUSH and state transfer during high invocation load

by vblagojevic＠jboss.com

We have agreed to implement the fix in block/unblock callbacks of CacheImpl. Thus the fix will be included in JBC 2.0 release. We will investigate if FLUSH needs semaphore A we talked about. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068771#4068771 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068771

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Knowledge of redelivery

by bill.burke＠jboss.com

I'll answer your question with a question: Why would a JMS receiver be interested on whether or not a message was redelivered? Maybe a node does not support redelivery of the message. Maybe a node needs to take additional action on a redelivery. Maybe you are executing a remote service that doesn't support transactions and that may have been executed. So you'll want to transition to a different state that compensates for this. Since jBPM uses a one size fits all approach for transitioning through JMS you don't have the option of tweaking message delivery semantics on a per node basis. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068717#4068717 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068717

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Barging in with a bug report

by estaub

Johan wrote: How can one go about to submit patches for these issues? Ronald wrote: either file 'issue' reports or show you have real skills and file patches and get committer access. ummm.... I think Johan just asked how to file patches. -Ed View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068702#4068702 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068702

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: JBossAppParsingDeployer issue

by adrian＠jboss.org

This is wrong. e.g. What if I want to deploy an EAR programatically where I tell it upfront what the structure and metadata is. i.e. it doesn't go through either the structure or the parsing deployer, it uses the structure and metadata I've told it to use when I did the programmtic deployment. I'm I supposed to know to add the transient managed object that represents the context root to the war context I create manually, or should I expect it to pick it from the J2eeApplicationMetaData where I defined it? The correct solution is to have a seperate deployer that looks for application level metadata when processing subdeployments. In principle there is not just the context-root that can defined at the ear level, one could also provide things like a default "call-by-value" in jboss-app.xml, etc. The creator of the deployment (including the profile service) should not be expected to know what transient managed objects need to be created. That is just an implementation detail of one way the deployers can "talk to each other". Also to make this work at all, the transient managed objects would have to be serialized such that a remote caller can add this information and the profile service can remember what they were when re-creating the deployment, this doesn't sound correct to me. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068664#4068664 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068664

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Knowledge of redelivery

by kukeltje

Bill, Do you have any usecase? We use jms internally in our company and have never been interested in these kinds of info. It is just like someone that sends a package via DHL/UPS/TNT is not interested in how many times a guy/girl went to the house an no-one was there. You only want to know it did or did not get delivered. The setRedelivery() could be interesting. Have to give it more thoughts thought. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068562#4068562 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068562

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Barging in with a bug report

by kukeltje

either file 'issue' reports or show you have real skills and file patches and get committer access. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068558#4068558 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068558

17 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2007