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."
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).
> 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$Default.java 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.
>> 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.
>>>> 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.
>>>>> 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