Re: [ljc] RFC - Default service implementation structure

From: user 1.
Sent on: Monday, March 11, 2013 2:36 PM

Sent from my iPhone

On 11 Mar 2013, at 13:54, Wesley Hall <[address removed]> wrote:


Thanks, interesting stuff. 

I am a bit of a spring fanboy these days (I recently even got a patch accepted \o/, overdue probably, I have been living off the fruits of their labour for a while), so I don't often use the technologies that you mention with the exception, perhaps of CDI. I don't event tend to use the CDI standard annotations because I prefer the spring ones (@Component > @Named imo). 

Having started with EJB at v1.0 the very mention of the acronym tends to send me cowering in a corner somewhere, despite the fact that I know that version 3 is much improved. 

I also avoid SOAP (pause for giggles re: hygiene related irony), though I use REST quite a lot. 

I suppose, ultimately, it will be my integration tests that form the defacto verification that something does/doesn't work, but it is quite right to consider the spec to at least understand that if something does work, you may be relying on a particular 'quirk' in a given implementation, and that switching might result in lots of headache. 

I still don't know whether what I am doing is really that good of an idea, it looks fairly nice to me, and I know that it would not take me long to use standard IDE refactorings to move to something more typical. 

Always useful to ask these questions, and have these discussions though, thank heavens for Socrates and his method, or, to quote a favourite fictional character of mine...

"If it wasnt for Socrates, that raving untreated schizophrenic, we wouldnt have the Socratic method — the best way of teaching everything, apart from juggling chainsaws."


On Mon, Mar 11, 2013 at 6:59 AM, Gerald Loeffler <[address removed]> wrote:
On Friday, March 8, 2013, Wesley Hall wrote:

Are you saying that the specs explicitly state that components should
be top level classes? Do you have a reference for that? I don't say

yes, that's exactly what i meant. Investigating a bit it turns out though, that for the current release (6) of Java EE i was also wrong in some cases:

- EJB session beans: section 4.9.2 of the "Enterprise JavaBeans 3.1" spec says "The class must be defined as public, must not be final, and must not be abstract. The class must be a top level class. [...]"

- SOAP webservice endpoints (that are not also session beans and hence restricted by the above requirement): section 3.1 of "Web Services Metadata for the Java Platform" spec says "A JSR-181 service implementation bean MUST meet the following requirements: The implementation bean MUST be an outer public class, MUST NOT be final, and MUST NOT be abstract. [...]"

- RESTful services (that are not also session beans and hence restricted by the above requirement): section 3.1 of the JAX-RS 1.1 spec says "A resource class is a Java class that uses JAX-RS annotations to implement a corresponding Web resource. Resource classes are POJOs [...]"
Not sure if a static inner class is normally considered a POJO, though.
Also, the spec doesn't define how automatic discovery of resources is to be done, because section 2.1 says "an implementation MAY provide alternate mechanisms for locating resource classes and providers (e.g. runtime class scanning) but use of Application is the only portable means of configuration."

- CDI: section 3.1.1 of the CDI spec ( says: "A top-level Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification, or if it meets all of the following conditions: It is not a non-static inner class [...]"

So, session beans and SOAP webservice endpoints can't be static inner classes, RESTful services (resources) that are not session beans can be, but it's implementation-dependent if they will be automatically discovered or not, while CDI managed beans clearly can be static inner classes.


this in a, "pics or it didn't happen!" way, I am just interested in
reading what they say on it, and it sounds like you have a better
knowledge of the specs and/or have looked at them more recently and
could save me a fairly long search.



On Fri, Mar 8, 2013 at 9:55 AM, Gerald Loeffler
<[address removed]> wrote:
> you're right that there is that separate, seemingly stand-alone
> class-file for each static inner class, which the class-path scanner
> might pick up if instructed to find all classes with a certain
> annotation (@Component, for instance). The de-facto standard for
> class-path scanning seems to be ASM, so in some way it depends how ASM
> behaves in that respect.
> What i don't know is if the byte-code of a static inner class actually
> identifies it as an inner class - or if it's just compiler magic, as
> you say, and all the information about the class-relationship is just
> in the class name ($). In any case, once the class is loaded,
> reflection does tell you if it's an inner class or not.
> Where there is a spec, however, i.e. for all Java EE technologies but
> not for Spring, the situation is more clear-cut insofar as i would
> stay away from doing anything (like using inner classes for
> components) that the spec prohibits - even if in practice it happens
> to work (unless there's a very good reason to violate the spec).
>   cheers
>   gerald
> On Fri, Mar 8, 2013 at 7:52 AM, Wesley Hall <[address removed]> wrote:
>> I would actually be interested to try this out.
>> I am not sure it really is that clever of spring really. Inner classes
>> (to my knowledge) are all just compiler magic. Post-compilation there
>> isn't really anything different about them, and I *think* that my
>> static inner implementation results in exactly the same compiler
>> output as if I had created a top-level class called
>> AccountService$ in the same package.
>> With this in mind I think you would have to go to extra effort to
>> exclude these classes from runtime annotations scanning (by rejecting
>> classes with $ in the name for example).
>> I am about 80% sure of this but someone with better knowledge of the
>> JVM (ping: Ben or Martijn) can probably confirm.
>> Wes
>> On Thu, Mar 7, 2013 at 4:30 PM, Gerald Loeffler
>> <[address removed]> wrote:
>>> On Thu, Mar 7, 2013 at 12:36 PM, Wesley Hall <[address removed]> wrote:
>>>> I am using DI with the spring annotations, spring has no problem
>>>> finding annotated static inner-classes though I am not sure about
>>>> other technologies.
>>> that's surprisingly clever of Spring (and not atypical for the
>>> attention to detail they typically show).
>>> For EJB and CDI, however, i'm certain that the specs demand that
>>> auto-discovered components are top-level classes. And i'd be surprised
>>> if this were different for JAX-WS and JAXRS webservice implementations
>>> (although i don't remember what the spec says).
>>>> I guess non-static inner classes will not work because they need a
>>>> reference to the containing instance.
>>> sure.
>>>   cheers
>>>   gerald
>>>> On Thu, Mar 7, 2013 at 10:55 AM, Gerald Loeffler
>>>> <[address removed]> wrote:
>>>>> I assume that any technology that depends on class-path scanning to
>>>>> automatically discover your service implementation (without you having
>>>>> to register it anywhere) will only find it if it is a top-level class.
>>>>> This means that your nested default service implementations cannot
>>>>> - be annotated with @Stateless to become stateless session beans
>>>>> - be CDI managed beans (which doesn't require them to be annotated)
>>>>> and so cannot be @Inject-ed
>>>>> - be annotated with Spring's @Component (or similar) in order to be
>>>>> auto-discovered as Spring beans
>>>>> - be auto-discovered as SOAP or REST webservice implementations
>>>>> - and probably many more.
>>>>> This is a purely technical point, of course.
>>>>>   cheers
>>>>>   gerald
>>>>> On Mon, Mar 4, 2013 at 12:25 PM, Wesley Hall <[address removed]> wrote:
>>>>>> Hello folks,
>>>>>> I have a little issue that I am sure has crossed the minds of a few
>>>>>> folks here and thought I would open it up for comments.
>>>>>> I am currently working on one of my little toy projects. I usually
>>>>>> have at least one of these on the go at any given point as it allows
>>>>>> me to play with new versions of libraries and technologies and also
>>>>>> lets me develop some of my ideas in terms of structure and layout.
>>>>>> Once again, I am finding myself visiting the age old problem of

Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Gerald Loeffler ([address removed]) from LJC - London Java Community.
To learn more about Gerald Loeffler, visit his/her member profile

Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Wesley Hall ([address removed]) from LJC - London Java Community.
To learn more about Wesley Hall, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

Our Sponsors

  • Our Blog

    Read the latest news from the LJC

  • RecWorks Ltd

    Fixing Tech Recruitment using the Power of Community

  • jClarity

    Java/JVM Performance Analysis Tools & mentoring for Java related matters

  • LJC Aggrity

    Our LJC Aggrity site contains blog posts from our members

  • LJC Book Club

    Our Book club with book reviews from our members

  • Devoxx UK

    Java Community Conference, in collaboration with the LJC 12/13 Jun 14

  • SkillsMatter

    "Host, help organise, promote, film many of our meetings."

  • New Relic

    New Relic makes sense of billions of metrics a day in real time.

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • Packt Publishing

    A publishing company specializing on specific technologies and solutions

  • Java.Net

    We are an official Java User Group recognised by Oracle's JUG program

  • JRebel

    Free 3 month J-Rebel license.

  • O'Reilly

    40% discount on printed books and 50% on e-books.

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy