Re: [jboss-dev-forums] [JBoss AS7 Development] - AS 7 Deployment APIs
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion
"AS 7 Deployment APIs"
To view the discussion, visit: http://community.jboss.org/message/559809#559809
--------------------------------------------------------------
So, people can understand it, I'll document my thinking a bit on why it was add(deployment).andDeploy(). (Cutting to the chase it can probably change.)
1. See my post above on 3 different parts of identifying a deployment -- common name, unique internal name, unique external name. That 3rd part unique external name is new from yesterday and is helpful. Without it the user needed a separate add operation so we could hash the deployment and come up with a unique name that's used in the other API methods. If instead we make the user responsible for providing a unique external name, that may simplify things.
2. In the domain case, we have a domain level <deployments/> element that lists all available deployments and then at the server-group level a mapping of deployments to server groups. And, within the server-group or on standalone server a deployment can have a start="false" flag. Those two facts imply a separate add operation that only makes content available but doesn't actually trigger deploy.
3. There are a lot of overloaded variants of "add". And I expect there will be more; see Jesper's suggestions on this thread, similar things that will probably come from Shrinkwrap. Adding all those overloaded variants to "deploy" and "replace" leads to an very busy API.
But, now I'm less concerned about 3). If the "unique external name" is the id for a deployment, all the methods that take DeploymentUnitKey can go and we're left with the String variants. And if the variants that take "String repository" as a param can go, that again wipes out a lot of overloading. So convenience methods for deploy and replace make sense.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559809#559809]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-dev-forums] [JBoss ESB Development] - Naming for webservice endpoints
by Keith Babo
Keith Babo [http://community.jboss.org/people/kcbabo] replied to the discussion
"Naming for webservice endpoints"
To view the discussion, visit: http://community.jboss.org/message/559795#559795
--------------------------------------------------------------
> For SOAPProcessor, how about also supporting the context defined on the "jbossws-endpoint" property (eliminating the need for the "jbossws-context" property) ala:<property name="jbossws-endpoint" value="myapp:fooservice"/>
This is an interesting alternative, although I would prefer to use a jbossws: scheme to clearly separate values for new config from the old config.
> For "pure" consistency between SOAPProcessor and SOAPProxy, couldn't they both be coded to also support exactly the same format for internal endpoints i.e.
>
> <property name="jbossws-endpoint" value="foo:HelloWorldWS"/>
>
> <property name="wsdl" value="foo:HelloWorldWS"/>
>
>
Now this is where things get really interesting. I was thinking that we couldn't have a config syntax that would make sense between SOAPProcessor and SOAPProxy, but I think you are on to something here. Only thing I would ask is that we actually use the jbossws: scheme (I think David suggested this in an email originally).
Re: the URI issue, a quick read of RFC 2396 leaves me with the impression that ":" is allowed in the path section of the URI. I could be misinterpreting it though; relevant definitions from the RFC below ...
<scheme>://<authority><path>?<query>path = [ abs_path | opaque_part ]abs_path = "/" path_segmentspath_segments = segment *( "/" segment )segment = *pchar *( ";" param )param = *pcharpchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+" | "$" | ","
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559795#559795]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-dev-forums] [JBoss AS7 Development] - Thoughts on hot deployment
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion
"Thoughts on hot deployment"
To view the discussion, visit: http://community.jboss.org/message/559791#559791
--------------------------------------------------------------
Ok so, I will first start off by saying that the file system is a *+broken+ API, for many reasons that I will get into, and that we basically have a bunch of trad*
> Dimitris Andreadis wrote:
>
> What is the rationale for the .deployed marker? It's really counter-intuitive. Just make a copy to avoid locking/classloading issues and leave the original in place.
The main reason was to support reusing information like indexes after a restart.
> Also, for exploded deployments have a different META-INF/jboss-deploy marker to trigger the deployment? Counter-intuitive as well. The whole idea with the ./deploy dir (or whatever is called) is you look there and you know what gets deployed, you don't need to traverse directories to find out. Or unzip something and it gets deployed, no need for extra files.
>
> IMO the AS4 model of hot-deployment (no VFS) was the most practival and successful. People knew that to avoid the "early deployment" problem for large or nested deployments they just have to do an atomic filesystem mv. Through stuff in and it just gets deployed, no markers or any other type of magic. I don't see why we need to re-discover the wheel.
Pretty much exploded deployments have always been broken. The atomic move only solves half of the problem, the deploy part, and it requires that it be on the same partition of an OS that supports atomic moves. During undeploy though, removing the directory causes classloader operations (namely getResource) to fail. This lead to a hack on AS5 where it would detect if the deployment used seam and then copy the whole thing, and then try to monitor and copy changed files.
The other issue is how you detect a redeploy operation. Historically this was touching the TLD, but since EE5 there is no gauranteed TLD (ejb deplyments could be pure annotations). Further modern frameworks use other descriptors besides the TLD which lead to AS5 detecting a change to ANY file and redeploying. This was a huge problem for our users, since a change doesn't necessarily mean you want a redeploy and we had to move back to the AS4 behavior which still doesnt fix the problem, since sometimes you have no way to cause a redeploy, and it also doesn't handle staged updates to files including the TLD. The marker though allows for someone to say I really actually want you to redeploy this.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559791#559791]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-dev-forums] [JBoss AS7 Development] - AS 7 Deployment APIs
by Alexey Loubyansky
Alexey Loubyansky [http://community.jboss.org/people/alex.loubyansky%40jboss.com] replied to the discussion
"AS 7 Deployment APIs"
To view the discussion, visit: http://community.jboss.org/message/559784#559784
--------------------------------------------------------------
Looks good!
> DeploymentPlan plan = deploymentManager.newDeploymentPlan() .withGlobalRollback()
> .add(war).andDeploy()
> .add(ear).andDeploy();
>
> The main part of the API is in the Builder interfaces that start from the return value from StandaloneDeploymentManager.newDeploymentPlan(). There are five basic operations:
>
> * add -- makes deployment content available to the standalone server or to the domain controller
> * deploy -- instruction that previously added content should be deployed on a standalone server or to one or more server groups
> * undeploy -- instruction that previously deployed content should be undeployed from a standalone server or from one or more server groups
> * replace -- atomic deply+undeploy. So if rollback is enabled and deploying the new content fails, the old content would be deployed
> * remove -- remove no longer deployed content from the repository where the standalone server or domain controller keeps content.
>
> I tried to create a fluent API so following one directive to the builder, logically coherent other directives become available, e.g.
>
> add(war).andDeploy()
Wouldn't having deploy([name,] war) be simpler? Same for replace.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559784#559784]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-dev-forums] [JBoss AS7 Development] - types of deployment errors and their handling
by Alexey Loubyansky
Alexey Loubyansky [http://community.jboss.org/people/alex.loubyansky%40jboss.com] replied to the discussion
"types of deployment errors and their handling"
To view the discussion, visit: http://community.jboss.org/message/559776#559776
--------------------------------------------------------------
> John Bailey wrote:
>
> I would like to add a couple definitions to the discussion.
>
> * Activation - The process step that is executing the service activators (sub-systems, Deployments, etc)
> * Service Start - The actual start operation on the services themselves
>
> The reason I want to separate these is the error handling should be different. Activation errors in subsystem should be considered catastrophic failures. These will certainly cause major failures further in the startup/runtime. In all likelihood these are not recoverable and will result in only portions of the sub-system services to be available. I feel this should result in halting the server start. I also think service start errors in a sub-system should halt the server startup process as well. I just don't think these can be recovered with a restart.
>
> What does everyone think?
If a service is an essential part of the subsystem then it's effectively a subsystem failure and the the server should stop.
> As for deployment activation errors, this has been discussed in previous posts, but in essence these should either rollback the batch or allow the previously added services to remain. Either way, the errors should be logged and server should continue the boot process. Deployment service start errors should also either stop the whole deployment or allow partial start based on user configuration.
I'd like to clarify what is this mechanism that is responsible for handling deployment activation errors. These errors pass by the listeners. They happen before the deployment is created and from this point of view they kind of aren't even deployment errors? Would any listener be notified at all if there was an activation failure? Can you imagine a listener that would be interested to receive a deployment activation error?
This kind of separation of activation and service start errors is confusing to me. You could have an exception hierarchy to differentiate between the two but why would you want to have different error handling mechanisms isn't clear to me.
Thanks.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559776#559776]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month