Right. I have updated the changes as you suggested.
Thanks,
- Hong
On 4/19/2011 12:11 AM, Jerome Dochez wrote:
> Hong
>
> I don't think we can change Sniffer in a dot release. it's supposed to be a public API. I think for now, the best we can do is come up with a new interface, probably a tag interface to denote secondary sniffers and mark our sniffers implementation with that interface when needed (like JPA). All non marked sniffer implementations should be treated as primary.
>
> jerome
>
> I wish we could use JDK7 already, with duck typed methods in interfaces...
>
>
> On Apr 18, 2011, at 8:09 PM, Hong Zhang wrote:
>
>
>> Hi, Chuk
>> The getIncompatibleSnifferTypes() method is currently used to reject deployment of application containing incompatible sniffers (e.g. due to packaging error). The method is not used to filter the sniffer list as it could be hard to guess user's true intention which sniffers to invalidate.
>> I just made some changes to relax the check in the DolProvider and return an empty Application when JavaEE metadata is not found. I also added a new API in Sniffer interface to indicate if the sniffer is a primary sniffer (so please implement this method for your main sniffer). Please try with tomorrow's 3.2 nightly build (or the next 3.2 promoted build) to see if you can remove the workarounds.
>> Thanks,
>>
>> - Hong
>>
>> On 4/18/2011 8:52 PM, Lee Chuk Munn wrote:
>>
>>> Hi Jerome
>>>
>>> wouldn't getIncompatibleSnifferTypes() solve this problem? If my
>>> sniffer is activated and contains a list of incompatible sniffers, then
>>> we should invalidate previously activated sniffers.
>>>
>>> I think this together with Metadata dependency should solve the problem.
>>>
>>> My 2 cents
>>>
>>> Regards
>>> Chuk
>>>
>>>
>>> On 19/04/11 02:26, Jerome Dochez wrote:
>>>
>>>
>>>
>>>> On Apr 18, 2011, at 11:12 AM, Hong Zhang wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>>>>> No, there is no ordering of the deployers. What happened in the stack trace (DolProvider) is that the GlassFish tried to process the JavaEE related metadata in the application and found none. Even though the GlassFish allows the plug in of extension container, we do assume the application still contains certain JavaEE components in addition to the extension components (except for special case like OSGI module). The GlassFish currently does not support deployment of pure extension module.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> that is an un-necessary limitation in my opinion. Why was this error message added ?
>>>>>>>> if there are no Java EE components, DolProvider should just return an empty Application object or null, I am not sure why it fails deployment all together. can you clarify ?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> This error message was added to fix issue
>>>>>>>
>>>>>>>
>>>>>>> http://java.net/jira/browse/GLASSFISH-11323
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There user tried to deploy an entity jar to the GlassFish and got a NPE. When I was fixing the issue, I was thinking we should not allow non-JavaEE archive like this to be deployed to GlassFish, so my fix was to reject the deployment with this error message.
>>>>>>>
>>>>>>> I guess we could relax the check to make this current use case to go through. But then in this issue I fixed where the user was deploying an entity jar as an ejb jar, he would not realize he made a mistake..
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> so the NPE should'nt have happen of course. What would happen if he deploys an entity jar with no DOL and components identified through Annotation, Isn't he going to get the "Cannot find a container capable of handing your jar file" type of message ? That's what should be happening.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Yes, that's what it would happen if user is trying to deploy a library jar. But in this case, the entity jar is recognized by the JPA sniffer (it contains a persistence.xml) and the current checking for no suitable container only checks if the retrieved sniffer list is empty or not..
>>>>>
>>>>>
>>>>>
>>>> so should we add a notion of secondary sniffer (naming probably wrong) where you can only find those sniffers in combination with at least one primary sniffer. So the logic for checking if the list of sniffer is empty could be enhanced so we check that we have at least one primary sniffer in our final list.
>>>>
>>>>
>>>>
>>>>
>>>>> - Hong
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/16/2011 2:57 AM, Lee Chuk Munn wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> I'm in the process of implementing JPA for my container (XARContainer)
>>>>>>>>>> which is not a JavaEE application. I've got XARContainer running, viz
>>>>>>>>>> this is the container that runs the actual component.
>>>>>>>>>>
>>>>>>>>>> I have a separate JPA container XJPAContainer, can't reuse existing
>>>>>>>>>> cause the app is not JavaEE, which handles JPA.
>>>>>>>>>>
>>>>>>>>>> I have indicated in my both my XJPASniffer and XARSniffer that its not
>>>>>>>>>> compatible with 'org.glassfish.persistence.jpa.JPASniffer'
>>>>>>>>>> (getIncompatibleSnifferTypes()).
>>>>>>>>>>
>>>>>>>>>> When I deploy my app, XJAPSniffer.handles() returns true. I've also
>>>>>>>>>> added some log statement which shows that XJPAContainer and XJPADeployer
>>>>>>>>>> have been instantiated by Glassfish. But for some reason,
>>>>>>>>>> XJPADeployer.prepare() was never called. Instead Glassfish is treating
>>>>>>>>>> my app as a JavaEE application so I'm getting an exception (see end of
>>>>>>>>>> this mail).
>>>>>>>>>>
>>>>>>>>>> My question is is there some sort of ordering for Deployers? Or is there
>>>>>>>>>> a way to get GF to give preferences to my deployer?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Chuk
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [#|2011-04-16T14:23:20.482+0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=54;_ThreadName=Thread-1;|Archive
>>>>>>>>>> [jpatest] was deployed as a Java EE archive while it does not contain
>>>>>>>>>> any valid Java EE components. Please check the packaging of the archive.
>>>>>>>>>> java.lang.RuntimeException: Archive [jpatest] was deployed as a Java EE
>>>>>>>>>> archive while it does not contain any valid Java EE components. Please
>>>>>>>>>> check the packaging of the archive.
>>>>>>>>>> at
>>>>>>>>>> org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:143)
>>>>>>>>>> at
>>>>>>>>>> org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
>>>>>>>>>> at
>>>>>>>>>> com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:826)
>>>>>>>>>> at
>>>>>>>>>> com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:768)
>>>>>>>>>> at
>>>>>>>>>> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
>>>>>>>>>> at
>>>>>>>>>> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
>>>>>>>>>> at
>>>>>>>>>> org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
>>>>>>>>>> at
>>>>>>>>>> com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>>
>
>