[Design the new POJO MicroContainer] - Re: Deployers Ordering Issue
by alesj
"richard.opalka(a)jboss.com" wrote :
| The fundamental question here is why do you think we shouldn't validate inputs?
I'm not completely saying we shouldn't do this,
I'm just saying does it really make sense, or are you just lazy? ;-)
"alesj" wrote :
| The only reasonable thing here might be that we check any previous stages for inputs,
| and potentially break (throw an exception) if some deployer requires an input from later output.
|
| But this should be properly discussed first on MC dev forum,
| as I'm still not convinced this is something we should do.
| e.g. we might just call it lazy deployer developer, as (s)he didn't bother to properly check previous deployers via statistics
I'm willing to add this check for dev usage, but not in production (*).
e.g. turn the check flag on, run/test the boot, and see if some deployer is broken
(*) the boot is already slow, w/o "helping" the "lazy"
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240005#4240005
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240005
15 years, 6 months
[Design the new POJO MicroContainer] - Re: Deployers Ordering Issue
by alesj
"richard.opalka(a)jboss.com" wrote :
| Rule no. 1: Always implement comparable if your object instances represents natural order.
|
There is a better rule.
Only implement what you actually need.
There is no need to really compare stages, at least not atm.
But you could do it this way:
ControllerStateModel model = ...;
DeploymentStage ds1 = ...;
ControllerState cs1 = new ControllerState(ds1.getString());
DeploymentStage ds2 = ...;
ControllerState cs2 = new ControllerState(ds1.getString());
boolean isBefore = model.isBefore(cs1, cs2);
"richard.opalka(a)jboss.com" wrote :
| "alesj" wrote :
| | If we have to resort to name comparison it either means:
| | * the order of how we process attachments doesn't matter
| | * you are describing/ordering your deployers wrong == lack of info
| |
| Sorry, I don't understand this? Could you explain me what do you mean, please.
What don't you understand?
If I need A and output B, and then need C and output D,
why should I care how are they ordered?
But if I in both cases need A and output B,
where in 1st deployer I set A.someprop
but in 2nd deployer I use that A.someprop,
all I need to do is express this via proper input/output,
e.g. D1.output=A.someprop, D2.input=A.someprop
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239999#4239999
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239999
15 years, 6 months
[Design the new POJO MicroContainer] - Re: Deployers Ordering Issue
by richard.opalka＠jboss.com
"alesj" wrote : "richard.opalka(a)jboss.com" wrote :
| | - it doesn't validate inputs
| |
| Validate how?
|
| Order at runtime based on the actual attachment values?
| Too much hassle for something that sounds useless in 99,9%.
| Not to mention that it's not deterministic.
|
By validating the input I mean:
if there's deployer that has input = "attachment_name", then
there's deployer before current deployer that defines output = "attachment_name".
I'm not talking about validating the deployer attachments at runtime.
"alesj" wrote : "richard.opalka(a)jboss.com" wrote :
| | - it sorts deployers on insert, but should sort them after deployers chain initialization
| |
| What would you gain by this?
I mean, how can you ensure deployers are inserted in correct order to deployers chain during AS bootstrap? This question is asked with precondition we're validating the deployers inputs as specified above.
The fundamental question here is why do you think we shouldn't validate inputs?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239998#4239998
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239998
15 years, 6 months
[Design the new POJO MicroContainer] - Re: Deployers Ordering Issue
by richard.opalka＠jboss.com
"alesj" wrote : "richard.opalka(a)jboss.com" wrote :
| | * deployer stages have to be comparable
| |
| Why?
| That's why they are called stages and they are already comparable - how else do you think they fit into our state machine. ;-)
|
Show me the code how would you compare two DeploymentStage instances?
Rule no. 1: Always implement comparable if your object instances represents natural order.
"alesj" wrote : "richard.opalka(a)jboss.com" wrote :
| | * deployers have to be sorted on deployers chain retrieval (i.e. in method protected synchronized List getDeployersList(String stageName))
| |
| Why?
| Based on what?
| This would be complete waste of time/performance.
|
I'd use the same trick Java iterators detect ConcurrentModificationException ;)
But not for throwing the exception, but for sorting the deployes chain only when necessary.
"alesj" wrote : "richard.opalka(a)jboss.com" wrote :
| | * sorting agorithm have to take stages, inputs, outputs and relative order into account
| |
| Why/how stages?
| All the rest is already taken into account.
|
Because deployers in previous stages can provide outputs that are required in next stages deployers (in their inputs).
"alesj" wrote : "richard.opalka(a)jboss.com" wrote :
| | * different sorting algorithm have to be implemented (domino is wrong because two deployers are not comparable in general)
| Sure.
| But re-read my previous post:
| "alesj" wrote :
| | If we have to resort to name comparison it either means:
| | * the order of how we process attachments doesn't matter
| | * you are describing/ordering your deployers wrong == lack of info
| |
Sorry, I don't understand this? Could you explain me what do you mean, please.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239988#4239988
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239988
15 years, 6 months
[Design of JBoss ESB] - Re: Supporting entry-point
by beve
anonymous wrote : There is a little more to this potentially than just configuring the names of a entry points in a single service. Entry points are relative to the StatefulKnowledgeSession. They allow for multiple event streams to populate the working memory. So for example the Order service could be configured to use the OrderStream, and a Customer service would be configured to use the CustomerStream. A third service would then be configured to create the StatefulKnowledgeSession and place this object in some location where it could be looked up and used to create the entry points by the other two services. This capability is perhaps not necessary as part of the Tech Preview, but should be kept in mind when designing the entry point logic.
I'm trying to understand the usecase here and this is my take on this:
1. OrderService (ESB service) uses rules and specifies an entry-point named "OrderEntryPoint".
2. CustomerService (ESB service) uses rules and specifies an entry-point named "CustomerEntryPoint".
3. DeliveryService (ESB service) uses rules and uses both of the above entry points.
If this is correct then why would the OrderService and CustomerService not simply produce a Order and Customer object and pass them to the DeliveryService instead of making the DeliveryService operate on the same StatefulKnowledgeSession.
Or have I totally misunderstood what you mean here :)
Jeff, could you help me understand what you are after and the usecase you have in mind?
Thanks,
/Daniel
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239972#4239972
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239972
15 years, 6 months
[Design of JBoss ESB] - Consistent handling of HTTP response header across HTTP comp
by tfennelly
This user forum thread raised an issue wrt to an inconsistency between how the HttpRouter is passing back Http response codes and how the JBossRemoting Gateway is extracting/expecting them from the message as it populates the JBoss Remoting response object.
The HttpRouter constructs a HttpResponse object. Into this, it populates the headers as HttpHeader instances, as well as setting the response payload. It then sets all this in a fixed (non-default) body location.
The SOAPClient doesn't map response headers at all, but it does use the MessagePayloadProxy for setting the response payload back on the ESB Message.
The JBR Gateway expects the http headers to be set as ResponseHeader instances in the message properties (org.jboss.soa.esb.message.ResponseHeader). It extracts the response payload from the message using a MessagePayloadProxy (so it expects it to be set in the Message Body).
The Embedded Tomcat Http Gateway works differently again. It expects the response headers to be set in a Map under a predefined (fixed) key in the message properties. It does however use the MessagePayloadProxy to get the response payload from the ESB Message.
So my preference would be:
1. All http invokers (HttpRouter, SOAPClient, ??) set the response headers in the message properties as ResponseHeader instances) and use the MessagePayloadProxy to set the response payload. The HttpRouter and SOAPClient both use the HttpClientFactory, so they should be able to use a common codebase for this.
2. All http gateways to expect the http response headers to be presented as outlined in #1 above.[/url]
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239944#4239944
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239944
15 years, 6 months