Re: [jboss-dev-forums] [JBoss AS7 Development] - Thoughts on filesystem action driven hot deployment
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion
"Thoughts on filesystem action driven hot deployment"
To view the discussion, visit: http://community.jboss.org/message/560107#560107
--------------------------------------------------------------
> Dimitris Andreadis wrote:
>
> > Jason Greene wrote:
> >
> >
> > The whole problem is the past approach doesnt work *+AT ALL.+ How do you trigger a redeploy of an exploded directory in a servlet 3.0 application that has no web.xml? So no matter what we do it will be different.*
> You obviously need to base the decision on the fact that something changed (file added/removed/edited). The smarter way would require somekind of knowledge per deployment type about where to look for changes. The dumb way would blindly assume the unit needs redeployment if anything changed (and in the case that Brian pointed out that you copy everything over, you know what's changed on every pass).
The latter approach was attempted in 5 and we had to rollback to 4 behavior because of the number of complaints issues around spurious errors it would cause. The former approach requires some kind of identifier, but we can't use deployment descriptors, since they might not be there. We can't use class files because they aren't required either (they might be in WEB-INF/lib). We also can't use the directory for the problems you mentioned earlier. So using a special deploy file is pretty much the only option, and IMO that's more intuitive than touching the TLD, since it's at least consistent across deployments.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/560107#560107]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-dev-forums] [JBoss AS7 Development] - Metadata processing
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion
"Metadata processing"
To view the discussion, visit: http://community.jboss.org/message/560073#560073
--------------------------------------------------------------
> Ales Justin wrote:
>
> > Annotation indexing was done by Jason.
> Where in Modules is this?
> It might be just me having trouble finding it with all this scattered git stuff ...
David is referring to a component I created awhile back:
http://github.com/jbossas/jandex http://github.com/jbossas/jandex
It's a generic, small low level component that indexes a set of classes (typically a jar) and provides an incomplete index (only from the viewpoint of those classes). It has no dependencies, and bypasses any kind of bytecode framework (javassist, asm, etc) so that it can take certain optimizations (not processing the full class, and skipping classes that don't have annotations). It also produces a space efficient index that is designed to be read quickly. It's intended to be attractive to all java projects, so that their is a strong incentive for users to index their jars, however initially we just care about fast domain performance.
This is only part of the puzzle though, as to have a complete picture the index lookups have to be aggregated to represent the class loader. That aggregation pattern would likely needed to be coordinated by an API that has the "complete" picture of module imports, deployments, etc (likely similar to AS6). The current Managed Bean impl uses it to index directly, however once the deployment repository is complete it can pull from index files that survive restart. The aggregation doesn't exist yet, and may or may not belong in modules.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/560073#560073]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[JBoss AS7 Development] - Steps in building up the domain management architecture
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] created the discussion
"Steps in building up the domain management architecture"
To view the discussion, visit: http://community.jboss.org/message/560046#560046
--------------------------------------------------------------
We currently have standalone servers starting and server managers starting and bringing up servers. The actual subsystems within the servers are proceeding pretty well and look to be on track for meeting M1 goals. The domain management infrastucture needs some beefing up though to get it where we need it for M1. For M1 I think we need:
* Server Manager booting Domain Controller booting, if so configuring
* Otherwise, Server Manager booting and discovering DC
* Basic deployments via the DC (does not include graceful shutdown; perhaps not some of the more complex deployment plan variants)
* Basic management operations via the DC
* Basic deployments via the Standalone server's mgmt interface
* Basic management operations via the Standalone server's mgmt interface
* Above done via a remote Java interface
* Good understanding of how above will be done via REST (not implemented, but thought through)
* "Transaction log" of deployments and other domain updates (I expect this will be refined post-M1)
* Filesystem based hot deploy on standalone server (unless Jason removes this from the list)
We've talked about CLI on some threads, but it seems CLI is not actually an M1 requirement, so we need to be careful about putting resources on it.
The immediate focus for myself is basic deployments via the Standalone server's mgmt interface as this allows folks working on subsystems and deployers to test properly what they are doing.
Fanning out from where we are now, we need:
h6. Basic Deployment Infrastructure
1. InVM programatic deployment. Now being worked by myself and John Bailey. Faciliates testing and serves as basis for
2. Remote Java deployment interface 1. also needs some standalone.xml configuration for the server management system's remote endpoint
3. Filesystem based hot deploy on standalone server
h6. Domain Controller Infrastructure
We need folks to start looking into this. Once we get far enough with the basic deployment infrastructure, I'm going to shift to it, but help from others is important.
1. Domain controller configuration. What subsystems are needed for the DC, how is their configuration expressed in domain.xml/host.xml
2. Server Manager boots DC if host.xml says there is a local DC.
3. Discovery mechanisms for the SM to find the DC. At least basic ones; we can add more post M1.
4. Communication protocols between DC and SM and on to Servers
h6. General Management Update Infrastructure
Emanuel Muckenhuber is looking into this. See for example https://community.jboss.org/thread/155860?tstart=0 https://community.jboss.org/thread/155860?tstart=0. This should also build off of and influence the basic deployment infrastructure, since deployments are just a form of management update.
We need to sort out an ordered approach to how this is going to be done and divide up subpieces so others can eventually help. E.g. will we start with standalone and then expand to DomainController-based updates? Or think it through from the DomainController side and work in? Or some mix? In general we should organize the work so progress is being made even while other pieces are incomplete; e.g. don't wait until all Domain Controller Infrastructure above is in place.
>From there we bring it all together and do deployments and management updates via the DC.
There are already JIRAs for quite a bit of this; I'll update this post later with JIRA references. Any comments, suggestions or expressions of desire to take on particular aspects are very much appreciated.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/560046#560046]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-dev-forums] [JBoss AS7 Development] - Thoughts on filesystem action driven hot deployment
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion
"Thoughts on filesystem action driven hot deployment"
To view the discussion, visit: http://community.jboss.org/message/560037#560037
--------------------------------------------------------------
> Dimitris Andreadis wrote:
>
> > David Lloyd wrote:
> >
> > > Dimitris Andreadis wrote:
> > >
> > > > Brian Stansberry wrote:
> > > >
> > > > Is it easier just to copy the exploded deployment and have the scanner keep the copy in sync. I've done that for farming; it's not such a big deal. I'm starting to feel like not doing that is leading to a lot of internal complication (e.g. needing to keep track of multiple locations where content is stored.)
> > > >
> > > > That doesn't solve the atomic move problem, but maybe if people can't do atomic moves they should use the filesystem as their deployment API. :)
> > > If the cost of deep copying and keeping in synch the exploded archive is not that high, that would solve the undeploy problems. Although I would personally leave the option to the user whether to disable deep copy of deployments, either globally (system property) or per deployment (e.g. META-INF/jboss-no-deep-copy).
> >
> > Actually this doesn't really solve the problem at all. Say you start deleting your deployment. At what point does the scanner decide that you're not updating your deployment by removing files, you're actually deleting it? The same problem basically exists except now you have the additional complication of having to detect and sync up changes. My opinion remains: using delete to signal undeploy should not be done, especially for exploded deployments.
> >
> > Thus, I don't see any reason to copy exploded deployments. I just don't think it buys us anything.
> I meant it would solve the problem of missing classes/resources during undeployment.
>
> In any case, I don't think you should worry too much about the timing related problems of deploying/undeploying exploded deployments. We have this problem for ever and yet very few complaint because they understand the limitations of the mechanism and how to deal with it. So IMO simplicity (copy/delete) wins over correctness since the main use case for altering exploded deployments is development mode.
The whole problem is the past approach doesnt work *+AT ALL.+ How do you trigger a redeploy of an exploded directory in a servlet 3.0 application that has no web.xml? So no matter what we do it will be different.*
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/560037#560037]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-dev-forums] [JBoss AS7 Development] - Thoughts on filesystem action driven hot deployment
by Dimitris Andreadis
Dimitris Andreadis [http://community.jboss.org/people/dimitris%40jboss.org] replied to the discussion
"Thoughts on filesystem action driven hot deployment"
To view the discussion, visit: http://community.jboss.org/message/560033#560033
--------------------------------------------------------------
> David Lloyd wrote:
>
> > Dimitris Andreadis wrote:
> >
> > > Brian Stansberry wrote:
> > >
> > > Is it easier just to copy the exploded deployment and have the scanner keep the copy in sync. I've done that for farming; it's not such a big deal. I'm starting to feel like not doing that is leading to a lot of internal complication (e.g. needing to keep track of multiple locations where content is stored.)
> > >
> > > That doesn't solve the atomic move problem, but maybe if people can't do atomic moves they should use the filesystem as their deployment API. :)
> > If the cost of deep copying and keeping in synch the exploded archive is not that high, that would solve the undeploy problems. Although I would personally leave the option to the user whether to disable deep copy of deployments, either globally (system property) or per deployment (e.g. META-INF/jboss-no-deep-copy).
>
> Actually this doesn't really solve the problem at all. Say you start deleting your deployment. At what point does the scanner decide that you're not updating your deployment by removing files, you're actually deleting it? The same problem basically exists except now you have the additional complication of having to detect and sync up changes. My opinion remains: using delete to signal undeploy should not be done, especially for exploded deployments.
>
> Thus, I don't see any reason to copy exploded deployments. I just don't think it buys us anything.
I meant it would solve the problem of missing classes/resources during undeployment.
In any case, I don't think you should worry too much about the timing related problems of deploying/undeploying exploded deployments. We have this problem for ever and yet very few complaint because they understand the limitations of the mechanism and how to deal with it. So IMO simplicity (copy/delete) wins over correctness since the main use case for altering exploded deployments is development mode.
Production mode users know that to be 100% safe they just need to make the directory based deployment changes off-line. Or use a proper API that can offer all sorts of guarantees (e.g. tx behaviour).
So offering the appropriate underying API/functionality to support the more advanced scenarios while keeping a simple file-based hot-delployment mechanism that people are familiar with, I think is more important than creating the perfect file-based API abstraction.
BTW, in some older AS version we added the ability to tell the scanner to ignore/re-enable a particular deployment, to allow the IDE to make file updates without the fear of the server picking up incomplete deployments.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/560033#560033]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[jBPM Development] - java.sql.SQLException: You cannot commit during a managed transaction!
by Abdurrahman Nasr
Abdurrahman Nasr [http://community.jboss.org/people/abdu_nasr] created the discussion
"java.sql.SQLException: You cannot commit during a managed transaction!"
To view the discussion, visit: http://community.jboss.org/message/560029#560029
--------------------------------------------------------------
Dears.
while i'm getting process engine in jbpm 4 using the following line
ProcessEngine processEngine = new Configuration().setResource("my.jbpm.cfg.xml").buildProcessEngine();
I encounter this problem
java.sql.SQLException: You cannot commit during a managed transaction!
at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.jdbcCommit(BaseWrapperManagedConnection.java:659)
at org.jboss.resource.adapter.jdbc.WrappedConnection.commit(WrappedConnection.java:486)
at org.hibernate.transaction.JDBCTransaction.commitAndResetAutoCommit(JDBCTransaction.java:170)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:146)
at org.jbpm.pvm.internal.tx.HibernateSessionResource.commit(HibernateSessionResource.java:64)
at org.jbpm.pvm.internal.tx.StandardTransaction.commit(StandardTransaction.java:139)
at org.jbpm.pvm.internal.tx.StandardTransaction.complete(StandardTransaction.java:64)
at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:57)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
and many more...
does any one know what is that exception about....?!
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/560029#560029]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-dev-forums] [JBoss AS7 Development] - Thoughts on filesystem action driven hot deployment
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion
"Thoughts on filesystem action driven hot deployment"
To view the discussion, visit: http://community.jboss.org/message/560026#560026
--------------------------------------------------------------
> Dimitris Andreadis wrote:
>
> > Brian Stansberry wrote:
> >
> > Is it easier just to copy the exploded deployment and have the scanner keep the copy in sync. I've done that for farming; it's not such a big deal. I'm starting to feel like not doing that is leading to a lot of internal complication (e.g. needing to keep track of multiple locations where content is stored.)
> >
> > That doesn't solve the atomic move problem, but maybe if people can't do atomic moves they should use the filesystem as their deployment API. :)
> If the cost of deep copying and keeping in synch the exploded archive is not that high, that would solve the undeploy problems. Although I would personally leave the option to the user whether to disable deep copy of deployments, either globally (system property) or per deployment (e.g. META-INF/jboss-no-deep-copy).
Actually this doesn't really solve the problem at all. Say you start deleting your deployment. At what point does the scanner decide that you're not updating your deployment by removing files, you're actually deleting it? The same problem basically exists except now you have the additional complication of having to detect and sync up changes. My opinion remains: using delete to signal undeploy should not be done, especially for exploded deployments.
Thus, I don't see any reason to copy exploded deployments. I just don't think it buys us anything.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/560026#560026]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-dev-forums] [JBoss AS7 Development] - Thoughts on filesystem action driven hot deployment
by Dimitris Andreadis
Dimitris Andreadis [http://community.jboss.org/people/dimitris%40jboss.org] replied to the discussion
"Thoughts on filesystem action driven hot deployment"
To view the discussion, visit: http://community.jboss.org/message/559963#559963
--------------------------------------------------------------
> Brian Stansberry wrote:
>
> Is it easier just to copy the exploded deployment and have the scanner keep the copy in sync. I've done that for farming; it's not such a big deal. I'm starting to feel like not doing that is leading to a lot of internal complication (e.g. needing to keep track of multiple locations where content is stored.)
>
> That doesn't solve the atomic move problem, but maybe if people can't do atomic moves they should use the filesystem as their deployment API. :)
If the cost of deep copying and keeping in synch the exploded archive is not that high, that would solve the undeploy problems. Although I would personally leave the option to the user whether to disable deep copy of deployments, either globally (system property) or per deployment (e.g. META-INF/jboss-no-deep-copy).
On the same topic, I'm not sure if you are aware or if this still holds true. In 4.x we essentially copyied over to tmp/deploy after prefixing some random name all archives from deploy on which we had to point a classloader, because the cl would lock the file and couldn't be deleted until the next restart. Same for any nested archive discovered through the expansion process (e.g. an ejb.jar found inside a zipped or an exploded .ear) So removing those archives from the copy location may not be possible.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559963#559963]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years