You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Peter H (JIRA)" <ji...@apache.org> on 2010/03/15 21:19:27 UTC
[jira] Created: (GERONIMO-5184) CLONE -Optional resource refs
CLONE -Optional resource refs
-----------------------------
Key: GERONIMO-5184
URL: https://issues.apache.org/jira/browse/GERONIMO-5184
Project: Geronimo
Issue Type: New Feature
Components: deployment
Reporter: Peter H
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.
[jira] Issue Comment Edited: (GERONIMO-5184) CLONE -Optional
resource refs
Posted by "Peter H (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-5184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845500#action_12845500 ]
Peter H edited comment on GERONIMO-5184 at 3/15/10 8:26 PM:
------------------------------------------------------------
So as I wrote in GERONIMO-556 - creating its clone and reposting again my comments that led me to do so to have it all at one place:
1.
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.
2.
Actually it would be great if also gbean-ref in geronimo-web.xml etc would be able to match to resource-ref in web.xml etc.
Have the following example with Work Manager and the explanation below:
web.xml entry
<resource-ref>
<res-ref-name>commonj/SomeWorkManager</res-ref-name>
<res-type>commonj.work.WorkManager</res-type>
<res-auth>Container</res-auth>
</resource-ref>
geronimo-web.xml entry:
<gbean-ref>
<ref-name>commonj/SomeWorkManager</ref-name>
<ref-type>javax.resource.spi.work.WorkManager</ref-type>
<pattern>
<name>SomeWorkManager</name>
</pattern>
</gbean-ref>
Then have the application externally configurable regarding the current implementation of WorkManager to be used
- on WAS/WLS set it to commonj - everything's fine
- on JBossAs (which can live with invalid resource-ref entry so no problem with deploy) set it to JBoss JCA WorkManager implementation and use that - everything's fine except that the resource-ref isn't valid but as I wrote JBoss doesn't have much troubles with that
- on Geronimo (which is currently unable to deploy the same ear/war) set it to Geronimo's JCA WorkManager and uyse that - everything would be fine if. one of the following would be met:
1. gbean-ref in geronimo-web.xml would match the resource-ref in web.xml, overriding the res-type from web.xml by ref-type from geronimo-web.xml and pointing to the desired gbean, then we would lookup the mapped component and use it properly (by externally configuring application to use the JCA WorkManager instead of CommonJ)
2. the resource-ref in web.xml (which is incorrect on Geronimo) would be ignored completely, application would deploy with that, via gbean-ref in geronimo-web.xml we would make the desired gbean accessible via JNDI and by externally configuring the app to use JCA WorkManager we would access it
3. we would add a resource-ref to geronimo-web.xml pointing to a WorkManager explicitly exposed via JNDI (which is fortunately possible) and that would match the resource-ref in web.xml, overriding the res-type from web.xml by ref-type from geronimo-web.xml again, with configuration setup for different case it should also work fine
4. the incorrect resource-ref in web.xml would be just ignored on Geronimo, we would expose the desired WorkManager via JNDI and access it directly via JNDI lookup without anything special in geronimo-web.xml
I think the first option would be the best, but others are also viable.
Note that currently Geronimo also complains about the class commonj.work.WorkManager not being found if the required commonj classes aren't added to classpath which should be here also possible to overcome.
I'll leave this issue for couple of days and if there will be no activity I'll probably open a duplicate of this (this one is closed and I can't reopen it) with these proposals.
The whole thing about which all this is is to make an application deployable on various application servers without the need to modify the actual ear/war file.
was (Author: hostalp):
So as wrote in GERONIMO-556 creating its clone and reposting again my comments that led me to do so do it will be at one place:
1.
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.
2.
Actually it would be great if also gbean-ref in geronimo-web.xml etc would be able to match to resource-ref in web.xml etc.
Have the following example with Work Manager and the explanation below:
web.xml entry
<resource-ref>
<res-ref-name>commonj/SomeWorkManager</res-ref-name>
<res-type>commonj.work.WorkManager</res-type>
<res-auth>Container</res-auth>
</resource-ref>
geronimo-web.xml entry:
<gbean-ref>
<ref-name>commonj/SomeWorkManager</ref-name>
<ref-type>javax.resource.spi.work.WorkManager</ref-type>
<pattern>
<name>SomeWorkManager</name>
</pattern>
</gbean-ref>
Then have the application externally configurable regarding the current implementation of WorkManager to be used
- on WAS/WLS set it to commonj - everything's fine
- on JBossAs (which can live with invalid resource-ref entry so no problem with deploy) set it to JBoss JCA WorkManager implementation and use that - everything's fine except that the resource-ref isn't valid but as I wrote JBoss doesn't have much troubles with that
- on Geronimo (which is currently unable to deploy the same ear/war) set it to Geronimo's JCA WorkManager and uyse that - everything would be fine if. one of the following would be met:
1. gbean-ref in geronimo-web.xml would match the resource-ref in web.xml, overriding the res-type from web.xml by ref-type from geronimo-web.xml and pointing to the desired gbean, then we would lookup the mapped component and use it properly (by externally configuring application to use the JCA WorkManager instead of CommonJ)
2. the resource-ref in web.xml (which is incorrect on Geronimo) would be ignored completely, application would deploy with that, via gbean-ref in geronimo-web.xml we would make the desired gbean accessible via JNDI and by externally configuring the app to use JCA WorkManager we would access it
3. we would add a resource-ref to geronimo-web.xml pointing to a WorkManager explicitly exposed via JNDI (which is fortunately possible) and that would match the resource-ref in web.xml, overriding the res-type from web.xml by ref-type from geronimo-web.xml again, with configuration setup for different case it should also work fine
4. the incorrect resource-ref in web.xml would be just ignored on Geronimo, we would expose the desired WorkManager via JNDI and access it directly via JNDI lookup without anything special in geronimo-web.xml
I think the first option would be the best, but others are also viable.
Note that currently Geronimo also complains about the class commonj.work.WorkManager not being found if the required commonj classes aren't added to classpath which should be here also possible to overcome.
I'll leave this issue for couple of days and if there will be no activity I'll probably open a duplicate of this (this one is closed and I can't reopen it) with these proposals.
The whole thing about which all this is is to make an application deployable on various application servers without the need to modify the actual ear/war file.
> CLONE -Optional resource refs
> -----------------------------
>
> Key: GERONIMO-5184
> URL: https://issues.apache.org/jira/browse/GERONIMO-5184
> Project: Geronimo
> Issue Type: New Feature
> Components: deployment
> Reporter: Peter H
> 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.
[jira] Commented: (GERONIMO-5184) CLONE -Optional resource refs
Posted by "Peter H (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-5184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845500#action_12845500 ]
Peter H commented on GERONIMO-5184:
-----------------------------------
So as wrote in GERONIMO-556 creating its clone and reposting again my comments that led me to do so do it will be at one place:
1.
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.
2.
Actually it would be great if also gbean-ref in geronimo-web.xml etc would be able to match to resource-ref in web.xml etc.
Have the following example with Work Manager and the explanation below:
web.xml entry
<resource-ref>
<res-ref-name>commonj/SomeWorkManager</res-ref-name>
<res-type>commonj.work.WorkManager</res-type>
<res-auth>Container</res-auth>
</resource-ref>
geronimo-web.xml entry:
<gbean-ref>
<ref-name>commonj/SomeWorkManager</ref-name>
<ref-type>javax.resource.spi.work.WorkManager</ref-type>
<pattern>
<name>SomeWorkManager</name>
</pattern>
</gbean-ref>
Then have the application externally configurable regarding the current implementation of WorkManager to be used
- on WAS/WLS set it to commonj - everything's fine
- on JBossAs (which can live with invalid resource-ref entry so no problem with deploy) set it to JBoss JCA WorkManager implementation and use that - everything's fine except that the resource-ref isn't valid but as I wrote JBoss doesn't have much troubles with that
- on Geronimo (which is currently unable to deploy the same ear/war) set it to Geronimo's JCA WorkManager and uyse that - everything would be fine if. one of the following would be met:
1. gbean-ref in geronimo-web.xml would match the resource-ref in web.xml, overriding the res-type from web.xml by ref-type from geronimo-web.xml and pointing to the desired gbean, then we would lookup the mapped component and use it properly (by externally configuring application to use the JCA WorkManager instead of CommonJ)
2. the resource-ref in web.xml (which is incorrect on Geronimo) would be ignored completely, application would deploy with that, via gbean-ref in geronimo-web.xml we would make the desired gbean accessible via JNDI and by externally configuring the app to use JCA WorkManager we would access it
3. we would add a resource-ref to geronimo-web.xml pointing to a WorkManager explicitly exposed via JNDI (which is fortunately possible) and that would match the resource-ref in web.xml, overriding the res-type from web.xml by ref-type from geronimo-web.xml again, with configuration setup for different case it should also work fine
4. the incorrect resource-ref in web.xml would be just ignored on Geronimo, we would expose the desired WorkManager via JNDI and access it directly via JNDI lookup without anything special in geronimo-web.xml
I think the first option would be the best, but others are also viable.
Note that currently Geronimo also complains about the class commonj.work.WorkManager not being found if the required commonj classes aren't added to classpath which should be here also possible to overcome.
I'll leave this issue for couple of days and if there will be no activity I'll probably open a duplicate of this (this one is closed and I can't reopen it) with these proposals.
The whole thing about which all this is is to make an application deployable on various application servers without the need to modify the actual ear/war file.
> CLONE -Optional resource refs
> -----------------------------
>
> Key: GERONIMO-5184
> URL: https://issues.apache.org/jira/browse/GERONIMO-5184
> Project: Geronimo
> Issue Type: New Feature
> Components: deployment
> Reporter: Peter H
> 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.