Hi Hong
just to add my thought to the discussion.
Some background to my current predicament: I wrote a container which is
a non JavaEE container and that got deployed. So I was thinking that I
could use JPA container but found that the current JPA container is
coupled tightly with JavaEE (requires Application in Metadata). So I
started a rewrite of the JPA container and that is where I ran into
problems.
Also I find the current GF behaviour a little inconsistent. If I deploy
my component into my container without persistent.xml, GF will not treat
my component as JavaEE. But the moment I have a persistent.xml then it
starts to assume that my app is a JavaEE archive.
Does GF looks at getIncompatibleSnifferTypes()? Also in
ApplicationLifecycle I notice that even though I provided my own
MetadataProvider, DolProvider is still called.
I work around the current issue my masquerading as a servlet.
Would be greate if we should remove this limitation and allow developers
to use individual containers eg JPA, CDI on their own.
TIA
Regards
Chuk
On 19/04/11 01:45, Hong Zhang wrote:
> Hi, Jerome
>>> 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..
>
> - 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)
>>>>
>>>>
>>
>>
--
I would love to change the world, but they won't give me the source code