You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Ryan <wi...@mandrake.us> on 2008/09/19 00:43:21 UTC
Transactions..... again!
I know this topic has come up a few times on the list but I wanted to
rehash some ideas again.
I'm using Spring/Hibernate/Declarative Transactions. We try to keep our
data-models rich and that helps a lot with transactional support
(services direct the rich-models and commit at the end of the service
call).
I still occasionally run into times when I want the onSubmit in a form
to start a transaction. I've basically decided to just use Spring's
programmatic transaction demarcation in those areas. Ive seen Igor
mention Salve, but I could not find any good examples, and I am not very
familier with Guice.
Aside from these ideas, has anyone used a different method for starting
transactions inside of wicket when needed?
Thanks!
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Transactions..... again!
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Sep 18, 2008 at 11:20 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> aspectj is pretty cool, but its expression language is somewhat
> limited. for example salve allows
>
> public void somefunction(@NotNull Integer a, @NotEmpty String b) {}
>
> aspectj, at least when i started salve, did not have an expression
> that would let you match a function if its argument was annotated with
> a specific annot.
Point taken. I'm not sure about this particular case, but I know the
annotation support for AspectJ has been improved.
>
> also i need things like removing/adding fields and contributing to
> clinit. aspectj is great for quickly matching on something and then
> adding something around, not for complex bytecode manipulation.
AspectJ can add in fields, but it's not good at adding in a
dynamically-generated set of fields.
>
> i started out writing salve with javassist, but i got tired of writing
> java code in strings. i wanted to be in complete control of bytecode
> to make sure it was as efficient as possible so in the end i learned a
> bit about bytecode and ended up using ASM.
Javassist can be a big PITA at first. The HiveMind project has helper
classes around it to assist with stuff, but it was still confusing.
That's one of the reasons I wrote Apache Commons Proxy, so I wouldn't
have to write another bit of Javassist to do proxying! :)
Thanks for taking the time to discuss. I'm going to have to check out
Salve a bit more in-depth. It's going into my Geek Queue! :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Transactions..... again!
Posted by Igor Vaynberg <ig...@gmail.com>.
aspectj is pretty cool, but its expression language is somewhat
limited. for example salve allows
public void somefunction(@NotNull Integer a, @NotEmpty String b) {}
aspectj, at least when i started salve, did not have an expression
that would let you match a function if its argument was annotated with
a specific annot.
also i need things like removing/adding fields and contributing to
clinit. aspectj is great for quickly matching on something and then
adding something around, not for complex bytecode manipulation.
i started out writing salve with javassist, but i got tired of writing
java code in strings. i wanted to be in complete control of bytecode
to make sure it was as efficient as possible so in the end i learned a
bit about bytecode and ended up using ASM.
-igor
On Thu, Sep 18, 2008 at 7:14 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Thu, Sep 18, 2008 at 9:48 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> read my email, i said it is possible without salve. salve just makes
>> it easier by letting you put the annotation on any method of any
>> class.
>>
>
> Ok, the Spring annotations/aspects do have a limitation that they need
> to be on at least protected methods, I think.
>
>> salve ships with 3 instrumentation options. there is the agent for
>> load time weaving, a maven2 plugin for compile time weaving, and an
>> eclipse plugin for dev time weaving.
>
> Cool. So, why doesn't Salve just use aspects and AspectJ to achieve
> what it wants (AspectJ supports the same 3 instrumentation options)?
> Did you write your own instrumentation? Do you not like the
> syntax/architecture of AspectJ? Just curious. I'm all about writing
> stuff my own way. :)
>
>>
>> i have also recently added something cool for wicket - expression
>> checking. if you use salve's contract instrumentor you can have it
>> validate property expressions, so you can do
>>
>> new PropertyModel(contact, new PE(Contact.class,
>> "address.street1").toString()) and get an instrumentation, read
>> compile, time error if there is no contact.getaddress().getstreet1().
>> doesnt refactor like the proxy idea but is also much more light weight
>> and works on map and list properties.
>
> That is pretty cool!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Transactions..... again!
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Sep 18, 2008 at 9:48 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> read my email, i said it is possible without salve. salve just makes
> it easier by letting you put the annotation on any method of any
> class.
>
Ok, the Spring annotations/aspects do have a limitation that they need
to be on at least protected methods, I think.
> salve ships with 3 instrumentation options. there is the agent for
> load time weaving, a maven2 plugin for compile time weaving, and an
> eclipse plugin for dev time weaving.
Cool. So, why doesn't Salve just use aspects and AspectJ to achieve
what it wants (AspectJ supports the same 3 instrumentation options)?
Did you write your own instrumentation? Do you not like the
syntax/architecture of AspectJ? Just curious. I'm all about writing
stuff my own way. :)
>
> i have also recently added something cool for wicket - expression
> checking. if you use salve's contract instrumentor you can have it
> validate property expressions, so you can do
>
> new PropertyModel(contact, new PE(Contact.class,
> "address.street1").toString()) and get an instrumentation, read
> compile, time error if there is no contact.getaddress().getstreet1().
> doesnt refactor like the proxy idea but is also much more light weight
> and works on map and list properties.
That is pretty cool!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Transactions..... again!
Posted by Igor Vaynberg <ig...@gmail.com>.
read my email, i said it is possible without salve. salve just makes
it easier by letting you put the annotation on any method of any
class.
salve ships with 3 instrumentation options. there is the agent for
load time weaving, a maven2 plugin for compile time weaving, and an
eclipse plugin for dev time weaving.
i have also recently added something cool for wicket - expression
checking. if you use salve's contract instrumentor you can have it
validate property expressions, so you can do
new PropertyModel(contact, new PE(Contact.class,
"address.street1").toString()) and get an instrumentation, read
compile, time error if there is no contact.getaddress().getstreet1().
doesnt refactor like the proxy idea but is also much more light weight
and works on map and list properties.
-igor
On Thu, Sep 18, 2008 at 6:42 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> I didn't think so. My apologies if I misunderstood. I was talking
> about using the spring-aspects stuff and having the AspectJ compiler
> weave the aspects into your code at compile time. Isn't Salve a
> load-time weaver?
>
> On Thu, Sep 18, 2008 at 8:37 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> isnt that what i said?
>>
>> -igor
>>
>> On Thu, Sep 18, 2008 at 4:11 PM, James Carman
>> <ja...@carmanconsulting.com> wrote:
>>> You don't need Salve for that. You can just use the AspectJ compiler
>>> and weave the transactional support into your form class.
>>>
>>> On Thu, Sep 18, 2008 at 6:49 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>> with salve you can do a neat thing:
>>>>
>>>> class transactionalform extends form {
>>>> @Transactional process() {
>>>> super.process();
>>>> }
>>>> }
>>>>
>>>> now if your form uses an ldm that loads an entity you dont even need
>>>> an onsubmit, things just get updated automatically because model
>>>> updates happen within a transaction.
>>>>
>>>> you can do the same without salve but you will have to manually start
>>>> and commit/rollback the transaction.
>>>>
>>>> this is probably the easiest way if you have a rich model and it
>>>> doesnt invole the somewhat ugly merge call. of course this wont work
>>>> for all forms, but for most i think it should.
>>>>
>>>> -igor
>>>>
>>>> On Thu, Sep 18, 2008 at 3:43 PM, Ryan <wi...@mandrake.us> wrote:
>>>>> I know this topic has come up a few times on the list but I wanted to
>>>>> rehash some ideas again.
>>>>>
>>>>> I'm using Spring/Hibernate/Declarative Transactions. We try to keep our
>>>>> data-models rich and that helps a lot with transactional support
>>>>> (services direct the rich-models and commit at the end of the service
>>>>> call).
>>>>>
>>>>> I still occasionally run into times when I want the onSubmit in a form
>>>>> to start a transaction. I've basically decided to just use Spring's
>>>>> programmatic transaction demarcation in those areas. Ive seen Igor
>>>>> mention Salve, but I could not find any good examples, and I am not very
>>>>> familier with Guice.
>>>>>
>>>>> Aside from these ideas, has anyone used a different method for starting
>>>>> transactions inside of wicket when needed?
>>>>>
>>>>> Thanks!
>>>>> Ryan
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Transactions..... again!
Posted by James Carman <ja...@carmanconsulting.com>.
I didn't think so. My apologies if I misunderstood. I was talking
about using the spring-aspects stuff and having the AspectJ compiler
weave the aspects into your code at compile time. Isn't Salve a
load-time weaver?
On Thu, Sep 18, 2008 at 8:37 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> isnt that what i said?
>
> -igor
>
> On Thu, Sep 18, 2008 at 4:11 PM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> You don't need Salve for that. You can just use the AspectJ compiler
>> and weave the transactional support into your form class.
>>
>> On Thu, Sep 18, 2008 at 6:49 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>> with salve you can do a neat thing:
>>>
>>> class transactionalform extends form {
>>> @Transactional process() {
>>> super.process();
>>> }
>>> }
>>>
>>> now if your form uses an ldm that loads an entity you dont even need
>>> an onsubmit, things just get updated automatically because model
>>> updates happen within a transaction.
>>>
>>> you can do the same without salve but you will have to manually start
>>> and commit/rollback the transaction.
>>>
>>> this is probably the easiest way if you have a rich model and it
>>> doesnt invole the somewhat ugly merge call. of course this wont work
>>> for all forms, but for most i think it should.
>>>
>>> -igor
>>>
>>> On Thu, Sep 18, 2008 at 3:43 PM, Ryan <wi...@mandrake.us> wrote:
>>>> I know this topic has come up a few times on the list but I wanted to
>>>> rehash some ideas again.
>>>>
>>>> I'm using Spring/Hibernate/Declarative Transactions. We try to keep our
>>>> data-models rich and that helps a lot with transactional support
>>>> (services direct the rich-models and commit at the end of the service
>>>> call).
>>>>
>>>> I still occasionally run into times when I want the onSubmit in a form
>>>> to start a transaction. I've basically decided to just use Spring's
>>>> programmatic transaction demarcation in those areas. Ive seen Igor
>>>> mention Salve, but I could not find any good examples, and I am not very
>>>> familier with Guice.
>>>>
>>>> Aside from these ideas, has anyone used a different method for starting
>>>> transactions inside of wicket when needed?
>>>>
>>>> Thanks!
>>>> Ryan
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Transactions..... again!
Posted by Igor Vaynberg <ig...@gmail.com>.
isnt that what i said?
-igor
On Thu, Sep 18, 2008 at 4:11 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> You don't need Salve for that. You can just use the AspectJ compiler
> and weave the transactional support into your form class.
>
> On Thu, Sep 18, 2008 at 6:49 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> with salve you can do a neat thing:
>>
>> class transactionalform extends form {
>> @Transactional process() {
>> super.process();
>> }
>> }
>>
>> now if your form uses an ldm that loads an entity you dont even need
>> an onsubmit, things just get updated automatically because model
>> updates happen within a transaction.
>>
>> you can do the same without salve but you will have to manually start
>> and commit/rollback the transaction.
>>
>> this is probably the easiest way if you have a rich model and it
>> doesnt invole the somewhat ugly merge call. of course this wont work
>> for all forms, but for most i think it should.
>>
>> -igor
>>
>> On Thu, Sep 18, 2008 at 3:43 PM, Ryan <wi...@mandrake.us> wrote:
>>> I know this topic has come up a few times on the list but I wanted to
>>> rehash some ideas again.
>>>
>>> I'm using Spring/Hibernate/Declarative Transactions. We try to keep our
>>> data-models rich and that helps a lot with transactional support
>>> (services direct the rich-models and commit at the end of the service
>>> call).
>>>
>>> I still occasionally run into times when I want the onSubmit in a form
>>> to start a transaction. I've basically decided to just use Spring's
>>> programmatic transaction demarcation in those areas. Ive seen Igor
>>> mention Salve, but I could not find any good examples, and I am not very
>>> familier with Guice.
>>>
>>> Aside from these ideas, has anyone used a different method for starting
>>> transactions inside of wicket when needed?
>>>
>>> Thanks!
>>> Ryan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Transactions..... again!
Posted by James Carman <ja...@carmanconsulting.com>.
You don't need Salve for that. You can just use the AspectJ compiler
and weave the transactional support into your form class.
On Thu, Sep 18, 2008 at 6:49 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> with salve you can do a neat thing:
>
> class transactionalform extends form {
> @Transactional process() {
> super.process();
> }
> }
>
> now if your form uses an ldm that loads an entity you dont even need
> an onsubmit, things just get updated automatically because model
> updates happen within a transaction.
>
> you can do the same without salve but you will have to manually start
> and commit/rollback the transaction.
>
> this is probably the easiest way if you have a rich model and it
> doesnt invole the somewhat ugly merge call. of course this wont work
> for all forms, but for most i think it should.
>
> -igor
>
> On Thu, Sep 18, 2008 at 3:43 PM, Ryan <wi...@mandrake.us> wrote:
>> I know this topic has come up a few times on the list but I wanted to
>> rehash some ideas again.
>>
>> I'm using Spring/Hibernate/Declarative Transactions. We try to keep our
>> data-models rich and that helps a lot with transactional support
>> (services direct the rich-models and commit at the end of the service
>> call).
>>
>> I still occasionally run into times when I want the onSubmit in a form
>> to start a transaction. I've basically decided to just use Spring's
>> programmatic transaction demarcation in those areas. Ive seen Igor
>> mention Salve, but I could not find any good examples, and I am not very
>> familier with Guice.
>>
>> Aside from these ideas, has anyone used a different method for starting
>> transactions inside of wicket when needed?
>>
>> Thanks!
>> Ryan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Transactions..... again!
Posted by Ryan <wi...@mandrake.us>.
Igor,
This looks like it would be ideal, I'll read more about Salve and see if
I can get it working.
-Ryan
On Thu, Sep 18, 2008 at 03:49:23PM -0700, Igor Vaynberg exclaimed:
>with salve you can do a neat thing:
>
>class transactionalform extends form {
> @Transactional process() {
> super.process();
> }
>}
>
>now if your form uses an ldm that loads an entity you dont even need
>an onsubmit, things just get updated automatically because model
>updates happen within a transaction.
>
>you can do the same without salve but you will have to manually start
>and commit/rollback the transaction.
>
>this is probably the easiest way if you have a rich model and it
>doesnt invole the somewhat ugly merge call. of course this wont work
>for all forms, but for most i think it should.
>
>-igor
>
>On Thu, Sep 18, 2008 at 3:43 PM, Ryan <wi...@mandrake.us> wrote:
>> I know this topic has come up a few times on the list but I wanted to
>> rehash some ideas again.
>>
>> I'm using Spring/Hibernate/Declarative Transactions. We try to keep our
>> data-models rich and that helps a lot with transactional support
>> (services direct the rich-models and commit at the end of the service
>> call).
>>
>> I still occasionally run into times when I want the onSubmit in a form
>> to start a transaction. I've basically decided to just use Spring's
>> programmatic transaction demarcation in those areas. Ive seen Igor
>> mention Salve, but I could not find any good examples, and I am not very
>> familier with Guice.
>>
>> Aside from these ideas, has anyone used a different method for starting
>> transactions inside of wicket when needed?
>>
>> Thanks!
>> Ryan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Transactions..... again!
Posted by Igor Vaynberg <ig...@gmail.com>.
with salve you can do a neat thing:
class transactionalform extends form {
@Transactional process() {
super.process();
}
}
now if your form uses an ldm that loads an entity you dont even need
an onsubmit, things just get updated automatically because model
updates happen within a transaction.
you can do the same without salve but you will have to manually start
and commit/rollback the transaction.
this is probably the easiest way if you have a rich model and it
doesnt invole the somewhat ugly merge call. of course this wont work
for all forms, but for most i think it should.
-igor
On Thu, Sep 18, 2008 at 3:43 PM, Ryan <wi...@mandrake.us> wrote:
> I know this topic has come up a few times on the list but I wanted to
> rehash some ideas again.
>
> I'm using Spring/Hibernate/Declarative Transactions. We try to keep our
> data-models rich and that helps a lot with transactional support
> (services direct the rich-models and commit at the end of the service
> call).
>
> I still occasionally run into times when I want the onSubmit in a form
> to start a transaction. I've basically decided to just use Spring's
> programmatic transaction demarcation in those areas. Ive seen Igor
> mention Salve, but I could not find any good examples, and I am not very
> familier with Guice.
>
> Aside from these ideas, has anyone used a different method for starting
> transactions inside of wicket when needed?
>
> Thanks!
> Ryan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Transactions..... again!
Posted by Erik van Oosten <e....@grons.nl>.
Ryan,
Here is how I do this with Spring:
http://day-to-day-stuff.blogspot.com/2008/08/java-transaction-boundary-tricks.html
Its not as pretty as Salve's @Transactional but just as effective.
Regards,
Erik.
Ryan wrote:
> Aside from these ideas, has anyone used a different method for starting
> transactions inside of wicket when needed?
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org