I noticed that OSGI doesn't publish OSGI services when EJB extends an abstract class and is exported as OSGI service (with export-ejb:all).
(I use glassfish 3.1)
Is anyone familiar with this issue?
the manifest in EJB jar is:
<configuration>
<instructions>
<Export-EJB>ALL</Export-EJB>
...
</instructions>
</configuration>
thanks
Upd: the problem is solved if EJB directly implements an interface (instead of extending a class that implements this interface).
Did you also post this question in glassfish forum? Anyway, I replied there and the bottom line is it seems to me that super class interfaces are not considered business interfaces by default. See http://markmail.org/message/rirpdzw3r65gmng3 for detailed explanation.
Related
I have some individual web services written with spring boot that run individually and I want to create group projects based on needs.
Right now, the controllers are annotated with the #RestController annotation and obviously, they are working fine when the apps run individually.
But I want to convert these projects into maven dependencies, where I just pass them as dependencies and the controllers can exist by just that.
I have converted these projects into executable dependencies by adding classifier = exec.
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<classifier>exec</classifier>
</configuration>
</plugin>
On other projects with only components/services, this approach work since it is just autowiring the service class.
On the group project, I still can autowire the controllers and run the functions which is okay. But those controller classes have #RestController and #RequestMapping annotations and I was wondering if it is possible to activate those controllers without doing anything?
Like just add the dependency and the controllers of that dependency are there.
I have a spring boot rest service that included an external project in pom as it's dependency. That external project is basically a jar that has spring AOP code.
The base package in my main application that includes this external jar with spring AOP code is x.y.z
The class in external jar where the #before advice is, is under the package a.b.c
With this class under a.b.c package, it doesn't get recognized by the main application where I want to use the spring aop implementation and apply the aspect. However, when I change it's package from a.b.c to x.y.z (which I really can't do in real life) it works fine.
I know that in spring boot service which happens to be the including service, it scans everything under root package given in the application class, x.y.z in this case and that is why aspect works fine if it's class is under x.y.z.
however, the problem is that this spring app jar will be used across multiple applications. So changing package name like this is not an option.
Is there a way to accomplish this without changing the package name of the class where spring app code is ?
Probably component scan is only activated for your application class packages by default. You can extend it to multiple packages, including the aspect package:
XML style configuration:
<context:component-scan base-package="x.y.z, a.b.c" />
Annotation style configuration:
#ComponentScan(basePackages = {"x.y.z", "a.b.c"})
Disclaimer: I am not a Spring user, only an AspectJ expert. I just knew that you can configure component scan, googled the syntax for you and hope it is correct.
Please define the bean (of jar project )inside main application. Give the #ComponentScan(basePackages = {"x.y.z", "a.b.c"}) as well as #EnableAspectJAutoProxy. Also include below piece of code.
ex:
` #Bean
public LoggingHandler loggingHandler()
{
return new LoggingHandler();
}`
Also annotate external jar code with:
`#Aspect
#Component
public class LoggingHandler {`
What #kriegaex suggests is correct. In addition to that, please make sure you are using #Component along with #Aspect. Since #Aspect is not a Spring annotation, Spring won't recognize it and hence your aspect won't be registered. So, using #Component is mandatory to getting aspects to work in Spring environment.
I'm trying to extend an OSGI service. The OSGI service that is being extended includes some references and properties. I'm using the new org.osgi.service.component.annotations package. The meta XML generated by the annotations processor of OSGi R6 implementation does not account for the reference and property declarations made in the OSGI service I'm extending.
Apache Felix Maven SCR plugin handles this use case well and the class annotated with Felix annotations includes references and properties of the base class as well.
Is there a way to get this working with the official OSGI annotation implementation. I don't want to fallback to Felix SCR plugin unless I have to as their official website says to move on to the OSGI implementation and this is a new project where SCR plugin is not already in use.
The meta XML generated by the annotations processor of OSGi R6 implementation does not account for the reference and property declarations made in the OSGI service I'm extending.
The behaviour you are expecting is down to the build tool you are using to generate the XML, not the annotations themselves. In general it is not a good idea to generate the XML based on annotations found in the parent class. This is because the parent class located at build time may not be the same as the parent class located at runtime. In this situation it is possible that generated injection sites might not actually be present at runtime, causing lots of problems. In fact even if the type is the same, you are referencing private details of the parent class from the subclass.
That warning aside, you are probably using a bnd-based tool, such as the maven-bundle-plugin or bnd-maven-plugin to generate the XML file. To avoid the issues I have mentioned bnd does not search the parent class of a component for annotations, but this behaviour can be overridden in configuration using the following instruction:
-dsannotations-options: inherit
If you add that configuration option then you should see the behaviour that you want, but it is strongly recommended that you do not do this when the parent class and child class are in different bundles.
Another option that doesn't require inheriting annotations from the base class is to redeclare the needed references in the component itself:
#Component(
service = SomeService.class,
reference = {
#Reference(
name = "baseClassField",
field = "baseClassField",
service = SomeOtherService.class
),
#Reference(
name = "otherBaseClassField",
field = "otherBaseClassField",
service = YetAnotherService.class,
cardinality=ReferenceCardinality.MULTIPLE,
policy=ReferencePolicy.DYNAMIC
)
}
)
public class MyServiceImplementation
extends AbstractSomeServiceBaseImpl
implements SomeService
{...}
The obvious disadvantage is that you explicitly hardcode the implementation details of the superclass, which may be even more wrong than implicitly inheriting them at build time. This way not only can the runtime class have different fields than the compile time dependency, but even at compile time when the base class changes you have to make sure to update your class to reflect the added, removed, or renamed fields.
For use in maven you can define in this way:
<plugins>
<plugin>
<groupId>biz.aQute.bnd</groupId>
<artifactId>bnd-maven-plugin</artifactId>
<version>3.5.0</version>
<executions>
<execution>
<id>run-bnd</id>
<goals>
<goal>bnd-process</goal>
</goals>
</execution>
</executions>
<configuration>
<bnd><![CDATA[-dsannotations-options: inherit]]></bnd>
</configuration>
</plugin>
</plugins>
IntelliJ 12.1.6 Ultimate, with following plugins enabled :
AspectJ Support
AspectJ Weaver
Spring Support
Spring Data
Spring AOP and #AspectJ
I have a Spring Roo project, which use Spring Data repository API. Following are snippet codes :
Repository class
package my.package;
#RooJpaRepository(domainType = Thing.class)
public interface ThingRepository {
}
Roo generated aspect file
privileged aspect ThingRepository_Roo_Jpa_Repository {
declare parents: ThingRepository extends JpaRepository<Thing, Long>;
declare parents: ThingRepository extends JpaSpecificationExecutor<Thing>;
declare #type: ThingRepository: #Repository;
}
Spring JPA config
<repositories base-package="my.package" />
But in xml file, IntelliJ told me
So whenever I use method like find/save in IntelliJ, it will be marked as "Cannot resolve method"
However, both IntelliJ and Maven compiles without any problem, just the method not resolvable in editor. What could be the problem?
Bad news, I think you must wait for that functionality. See this:
http://youtrack.jetbrains.com/issue/IDEA-59138
In short: Nowadays Intellij doesn't support AspectJ declare parents nor declare precedence
Intellij developers have been playing around with this feature since Intellij 11 (See the comments about No technical block, just lack of resources)
The issue is marked to be resolved on Intellij 14. How long is that? See that Intellij 13.1 is planned to be released on Q2 of 2014, so it will take a while.
I'm having a problem with #Transaction in Spring.
Basically, no transaction is created with the following message:
delaying identity-insert due to no transaction in progress
I posetd a full description of the problen in the Spring AOP forum
http://forum.springsource.org/showthread.php?132612-Transaction-management
Any suggestion would be appreciated!
Stefano
in your code you have defined the service like this:
#Service
#Configurable
public class ServiceImpl<T> implements Service<T> {
#Override
#Transactional
public T save(T entity) {
....
}
}
I do not know why you use the #Configurable annotation. If you do not need them (that is if you do not create an instance of this service via new) , I would remove them.
The reason is that I remember that spring docu say that #Configurable enable injection, but it does not say anything about load time weaving support enabled by #Configurable
Found the solution.
The problem was in the configuratoin. I added two elements context:spring-configured and context:load-time-weaver that mean two different things. The first one activate AspectJ compile time weaving (which I didn't understand), the second one activate AspectJ load time weaving. I think that these two elements don't work well together.
I decided to use compile time weaver and (after struggling a little bit...) I found that (obviously) external jars are not weaved with this configuration, simply because they have yet been built.
The easiest way to solve is to modify the configuration of the aspectj-maven-plugin (in POM.xml) adding under the configuration node:
<weaveDependencies>
<weaveDependency>
<groupId>GROUP-ID</groupId>
<artifactId>ARTIFACT-ID</artifactId>
</weaveDependency>
</weaveDependencies>
for every artifact you need to weave.
Now transactions work fine!
#Ralph: many thanks for your time!
Regards,
Stefano