[
https://issues.apache.org/jira/browse/DELTASPIKE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13855077#comment-13855077
]
John D. Ament edited comment on DELTASPIKE-399 at 12/22/13 3:18 AM:
--------------------------------------------------------------------
[~chkal] I'll create a separate ticket to make a priority interface/abstract
class & comparator. I agree, it's something we need globally.
When I first prototyping it, I actually used classpath: and file: to
differentiate. It definitely works more consistently, and I agree searching
through is a pain. At one point I had a `canProivde` method that indicated
whether or not the value could be read. I think the CDI-esque way would be to
use a qualifier on what prefix is handled.
Also, I think the only way to make it configurable, so app developers can add
more resource providers, is to make it a string. It can be a separate
attribute,e.g. @ExternalResource(storage="file",name="myapp.properties") and
@ExternalProperties(storage="classpath",name="myapp.properties")
actually, I looked at first at doing this in the servlet module. From what I'm
seeing, servlet support isn't actually needed for any use case, you can use
file to locate it. I didn't try in every app server mind you. Is there a
scenario you can think of that requires servlet context?
[~gpetracek] The reason @XMLProperties is a separate annotation is that it only
applies to property based loading. We can't scale well if we need to add new
attributes/enum values, and we make a lot of inter-dependency by adding them
unnecessarily. For example @XMLProperties wouldn't apply if the source was a
DB table. Now, this is slightly precluded since we're dealing with
inputstreams right now, so that may need to change.
was (Author: johndament):
[~chkal] I'll create a separate ticket to make a priority interface/abstract
class & comparator. I agree, it's something we need globally.
When I first prototyping it, I actually used classpath: and file: to
differentiate. It definitely works more consistently, and I agree searching
through is a pain. At one point I had a `canProivde` method that indicated
whether or not the value could be read. I think the CDI-esque way would be to
use a qualifier on what prefix is handled.
actually, I looked at first at doing this in the servlet module. From what I'm
seeing, servlet support isn't actually needed for any use case, you can use
file to locate it. I didn't try in every app server mind you. Is there a
scenario you can think of that requires servlet context?
[~gpetracek] The reason @XMLProperties is a separate annotation is that it only
applies to property based loading. We can't scale well if we need to add new
attributes/enum values, and we make a lot of inter-dependency by adding them
unnecessarily. For example @XMLProperties wouldn't apply if the source was a
DB table.
> Incorporate Solder's ResourceLoader features into DeltaSpike
> ------------------------------------------------------------
>
> Key: DELTASPIKE-399
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-399
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Core
> Affects Versions: 0.4
> Reporter: Aaron Siri
> Assignee: John D. Ament
> Priority: Minor
> Fix For: 0.6
>
>
> Seam 3's Solder module had some nice resource loading functionality within
> the org.jboss.solder.resourceLoader packages. With it you could do the
> following:
> // Load a properties file
> @Inject @Resource("app.properties")
> private Properties appProperties;
> or:
> @Inject
> private ResourceProvider resourceProvider
> public Properties getHostProperties() {
> String hostname = java.net.InetAddress.getLocalHost().getHostName();
> return resourceProvider.loadPropertiesBundle(hostname + ".properties");
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
