I'm trying to learn my way around Confluence before I started making
edits but I've got a question about how everything is setup.
The Editing the Documentation page says the content is:
Created here: http://cwiki.apache.org/confluence/display/WW/
http://struts.apache.org/2.x/docs/home.html
Chase on 01/05/08 06:04, wrote:
Adam Hardy wrote:
the problem was spurious JPA updates - which can be avoided by putting
an interceptor in between the Validation and the Workflow
interceptors: all it should do is call EntityManager.clear().
if (validationAwareAction.hasErrors())
Using the JPA extended persistence context (not EJB), the clear() will
eliminate any changes to the model before JPA comes to flush to the db. I
assume it would work in an EJB container too.
I'm not really sure I get the point your making here, but if you just do not
want the EntityManager
Alexander Snaps on 01/05/08 11:30, wrote:
Using the JPA extended persistence context (not EJB), the clear() will
eliminate any changes to the model before JPA comes to flush to the db. I
assume it would work in an EJB container too.
I'm not really sure I get the point your making here, but
Alexander Snaps on 01/05/08 11:30, wrote:
Using the JPA extended persistence context (not EJB), the clear() will
eliminate any changes to the model before JPA comes to flush to the db. I
assume it would work in an EJB container too.
I'm not really sure I get the point your making here, but
On Thu, May 1, 2008 at 12:49 PM, Adam Hardy
[EMAIL PROTECTED] wrote:
Alexander Snaps on 01/05/08 11:30, wrote:
Using the JPA extended persistence context (not EJB), the clear() will
eliminate any changes to the model before JPA comes to flush to the
db. I
assume it would work
Alexander Snaps on 01/05/08 12:02, wrote:
On Thu, May 1, 2008 at 12:49 PM, Adam Hardy
[EMAIL PROTECTED] wrote:
Alexander Snaps on 01/05/08 11:30, wrote:
Using the JPA extended persistence context (not EJB), the clear() will
eliminate any changes to the model before JPA comes to flush to the
Alexander Snaps on 01/05/08 12:02, wrote:
Entity myEntity = em.find(Entity.class, someId);
oldValue = myEntity.getSomeField(); // this is only for further down in the
mail ;)
myEntity.setSomeField(someValue);
if(!hasError) {
EntityTransaction tx = em.getTransaction();
tx.begin();
Don't really have the context indeed, I haven't been looking into the
Model-Driven and had no clue where this is happening. I just think this is
more correct than doing everything within the tx demarcation. And indeed
many people don't know about the tx.begin - commit in a row thing. I also
keeps
[ I suspect this is going to break threading Is there a good way to respond
to a message from a digest without breaking threading? )
Adam Hardy on 26/04/08 10:42, wrote:
I am pulling in what I wrote earlier because I should correct what I said
about letting entities slip out of scope.
Eric D Nielsen on 01/05/08 14:54, wrote:
[ I suspect this is going to break threading Is there a good way to respond
to a message from a digest without breaking threading? )
I wondered why! Unfortunately you need the message id for threading and I don't
think it is included in the
Am I wrong, or JPA's EntityManager has no support for anything like
evict()? I think this is an Hibernate's Session specific feature...
Alex
On Thu, May 1, 2008 at 3:54 PM, Eric D Nielsen [EMAIL PROTECTED] wrote:
[ I suspect this is going to break threading Is there a good way to
respond
Yes, you're right. There are also several other things lacking that I would find
useful. But I guess it's still version 1.
Alexander Snaps on 01/05/08 15:35, wrote:
Am I wrong, or JPA's EntityManager has no support for anything like
evict()? I think this is an Hibernate's Session specific
I know I am repeating myself, but what is getting in the way of NOT starting
a transaction at all in the case of a validation error... Shoudn't the
transaction be started much later anyways, and only if validation passed?
On Thu, May 1, 2008 at 4:51 PM, Adam Hardy [EMAIL PROTECTED]
wrote:
Yes,
I'm ready to commit this, but I guess I will wait until Don cuts the
new build. This is how it works:
1. Static content lookup was refactored to DefaultStaticContentLoader
which implements StaticContentLoader.
2. DefaultStaticContentLoader does everything FilterDipatcher did
before, but it also
We've had a fair amount of issues in the AppFuse project using *.html
as an extension. This is because some plugins and such use *.html
files and Struts attempts to serve them up as Actions rather than
plugins. Will this fix that problem? We've added a StaticFilter[1]
that attempts to fix it, but
As long as no mapping is found for that *.html, and it is inside one
of the lookup folders (like static) it should work.
musachy
On Thu, May 1, 2008 at 12:24 PM, Matt Raible [EMAIL PROTECTED] wrote:
We've had a fair amount of issues in the AppFuse project using *.html
as an extension. This
Yes, like this:
filter-classorg.apache.struts2.dispatcher.FilterDispatcher/filter-class
init-param
param-namepathPrefixes/param-name
param-value/super_folder/param-value
/init-param
musachy
On Thu, May 1, 2008 at 12:32 PM, Matt Raible [EMAIL PROTECTED] wrote:
Is it possible
While I used WebWork-2, and the XWork associated with it, I was able to
programmatically
retrieve action validation using the ActionValidatorManagerFactory.
Now, it seems this class was removed.
Any suggestions on how to programmatically get a ValidatorFactory instance?
The Struts 2.1.2 test build is now available.
Release notes:
* http://struts.apache.org/2.x/docs/version-notes-212.html
Distribution:
* http://people.apache.org/builds/struts/2.1.2/
Maven 2 staging repository:
* http://people.apache.org/builds/struts/2.1.2/m2-staging-repository/
Once you have
20 matches
Mail list logo
