[ 
https://issues.apache.org/jira/browse/GERONIMO-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798150#action_12798150
 ] 

Peter H commented on GERONIMO-556:
----------------------------------

Actually it would be useful for applications which are supposed to be deployed 
to various application servers.
For example we use couple of CommonJ WorkManagers which can be used on 
WebSphere or WebLogic.
For them Geronimo complains during deployment about inability to resolve their 
resource references and refuses to deploy the application.

However our application can be externally configured to not rely on the CommonJ 
WorkManagers so it's not an issue for us at all.

JBoss at least deploys it with some dummy entries in jboss-web.xml, but so far 
I didn't manage to get it deployed on Geronimo without having to comment out 
all the affected resource references in web.xml

At least some non-strict mode which would just give warnings instead of 
refusing to deploy completely would be great.
Something like Strict Manifest Classpath processing mode which can be altered 
by the -DXorg.apache.geronimo.deployment.LenientMFCP option.

> Optional resource refs
> ----------------------
>
>                 Key: GERONIMO-556
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-556
>             Project: Geronimo
>          Issue Type: New Feature
>          Components: deployment
>            Reporter: David Jencks
>            Assignee: David Jencks
>             Fix For: Wish List
>
>
> Right now, all resource refs (and other jndi entries) specified in a spec-dd 
> must be resolved during deployment or building the configuration will fail.  
> It's possible that some resource refs are optional and that the app can 
> function to  some extent with them missing.
> We could support this by including an optional "optional" marker in the 
> geronimo plan. The simplest implementation would attempt to resolve the ref 
> to an object name present during deployment, and use it if the name is found, 
> and bind nothing if the name is not found.  Then the app would get a naming 
> exception at runtime if it tried to look up the missing resource.
> We should decide what should happen when the entire target object name is 
> supplied.  We could use it to bind a reference, or only bind a reference if 
> the gbean is present at deploy-time.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to