incubator-hise-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Anderson <>
Subject Re: HISE Spring refactoring
Date Mon, 21 Jun 2010 14:04:59 GMT
Hi Rafal,

Please add 

  <name> Repository for Maven</name>

to the top level POM. The upgrade to the latest CXF release must have 
introduced that dependency.



From: Rafal Rusin <>
Sent: Mon, June 21, 2010 3:42:07 AM
Subject: Re: HISE Spring refactoring

Looks cool.
Where can I grab jaxb-fluent-api?


  Try downloading the file manually from the project website.

  Then, install it using the command:
      mvn install:install-file
-DartifactId=jaxb-fluent-api -Dversion=2.1.8 -Dpackaging=jar

  Alternatively, if you host your own repository you can deploy the file there:
      mvn deploy:deploy-file
-DartifactId=jaxb-fluent-api -Dversion=2.1.8 -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency:
      1) org.apache.cxf:cxf-codegen-plugin:maven-plugin:2.2.9

On 19 June 2010 20:10, Aaron Anderson <> wrote:
> Hi,
> I have commited some changes to my github hise fork at
demonstrating the removal of the Spring dependencies from the core HISE service classes. 
The motivation of my changes was to make HISE interoperable with other Java frameworks besides
Spring.More specifically, SCA or JSR 299 containers. Currently the first three SOAP UI tests
successfully execute and the last one fails at the very end with a WS-Addressing issue which
I am unsure is related to my change. Here are the relevant changes:
> 1) Removed the JpaTemplate in favor of EntityManager injection.
> 2) Added JSR 250 annotations for init/destroy methods
> 3) Added JSR 330 dependency injection annotations to declare injection points
> 4) Added a couple of service interfaces to better support injection and proxies
> 5) Created new Spring module to contain common Spring configurations and maven dependencies
between the OSGi and war modules
> 6) Removed all CXF references and used pure JAX-WS code
> 7) Created new transactional annotation for declarative transactions
> This last one is one of the more radical changes. Every framework seemingly has it's
own set of annotations for defining declarative transactions. Mike Keith from Oracle recently
gave a JPA 2.0 presentation nearby and I asked him about this and he said there is no desire
to create new JTA annotations in the JCP and to simply use EJB annotations. I researched into
this a bit and I believe I have determined a way to make portable declarative transaction
annotations. First I created a HISE specific @Transaction annotation. Then in the Spring module
I redefined the HISE @Transactional annotation to contain the Spring @Transactional annotation.
When the Spring container detects the HISE @Transactional annotation it knows that the Spring
@Transactional stereotype is applied to it and it will apply the appropriate transactional
semantics to the referenced Java methods. In a JSR 299 container this same approach can be
used to apply an @Interceptor annotation,
>  SCA the @Intent("managedTransaction") annotation can be used, and in a EJB container
the @TransactionManagement annotation.
> For the new Spring module I attempted to use autowiring with the JSR 330 annotations
but apparently with Spring annotation driven autowiring is either an all or nothing configuration.
Since autowiring would not work with the HISE spring deployment model I disabled it.
> Currently I am working on a JSR 299 module using openwebbeans to see if I can get HISE
running in that container. For this container I will need to come up with an alternative HISE
deployment mechanism in the absence of Spring and Unfortunately JAX-WS does not define a standard
deployment API so I will need to work through that challenge as well.
> Please checkout my fork and let me know your thoughts on my changes.
> Thanks,
> Aaron
> ________________________________
> From: Rafal Rusin <>
> To:
> Sent: Sun, May 2, 2010 7:11:54 AM
> Subject: Re: HISE Spring refactoring
> Hello,
> On 29 April 2010 20:22, Aaron Anderson <> wrote:
>> Hi Guys,
>> Sorry if this is a repost. I have started making changes to the HISE service module
in my github fork to remove references to the Spring implementation classes.  One change I
would like to make is to move the transactional code into a new service implementation and
then make transactional declarations on it in the Spring configuration. Are there any concerns
or comments on a move to declarative transactions?
> Well, on one hand this is good (I wanted to do it this way before),
> but on the other, I had for example problem configuring both
> @WebServiceContext and @Transactional (only one of them worked). So it
> looks like using too much annotations just doesn't work.
> The other problem is that such declarations spoil runtime somewhat,
> because are implemented using reflection, which is slower. I know some
> people like such things like annotations & AOP scoped proxies, but I
> prefer to write some additional code and have some control over what's
> going on (and cleaner stacktraces in logs). But this is just my
> opinion. So as long as it works, I'm open to accept it.
>> Thanks,
>> Aaron
>> ________________________________
>> From: Rafal Rusin <>
>> To:
>> Sent: Thu, March 25, 2010 7:47:17 PM
>> Subject: Re: question about hise=pendency while leaving the Spring configuration
intact. Would this be a contribution of interest for the project? The reason I am proposing
this is that I would like to embed HISE in an SCA framework and the SCA specification supports
JSR 250. Perhaps if I get it working I could contribute a standard SCA composite maven module
in addition to the war and OSGI bundle.
>> You can try to do this. Please open Jira issue and clone
>> repo (master branch). When you have
>> something working, provide info what we need to do in order to test
>> it.
>> As soon as it works, we'll apply your patch.
>> I suggest using git here, because it's a bigger work and git is good
>> for doing frequent merges with trunk.
>> Regards,
>> --
>> Rafał Rusin
> Regards,
> --
> Rafał Rusin

Rafał Rusin

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message