[jira] [Commented] (DELTASPIKE-472) Implement portable extensions that install custom beans when not running inside a WAR file.
[ https://issues.apache.org/jira/browse/DELTASPIKE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13855122#comment-13855122 ] Romain Manni-Bucau commented on DELTASPIKE-472: --- Hi I don't get it too, we agreed to add xml config, is it this? BTW module.xml is a bad name IMO and can conflict with some containers. apache-deltaspike-xxx.xml would be better IMO (xxx=cdi or config surely). > Implement portable extensions that install custom beans when not running > inside a WAR file. > --- > > Key: DELTASPIKE-472 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-472 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 0.6 > > > In many cases, when you deploy with CDI you're using a self contained WAR > that has everything in it. However, in certain deployment models you can > reference external classpath entries that could be available to you, but not > scanned based on CDI scanning rules. > To work with these more efficiently, we need to implement some extensions > that do very basic things, mostly installing custom beans at runtime to the > destination applications. > I'll go through the application and identify cases where we need to install a > bean, ignoring things that obviously don't belong, e.g. @Typed classes which > are understood to not be installed. At a minimum we should create extensions > that encompass our primary features, where they don't already exist - for > example, Partial Bean is already an extension and needs no other work, Bean > Validation doesn't need an extension since it can be configured, Servlet > simply needs to be registered. Most of this work seems to be in Core. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-475) auto. registration of jobs with cron-expressions
[ https://issues.apache.org/jira/browse/DELTASPIKE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13855121#comment-13855121 ] Romain Manni-Bucau commented on DELTASPIKE-475: --- Hi guys, I think we can support only quartz ATM. If we need another impl we'll just default to quartz later extracting the specific code...but honestly I doubt it and the API could even rely on quartz to stay simple IMHO > auto. registration of jobs with cron-expressions > > > Key: DELTASPIKE-475 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-475 > Project: DeltaSpike > Issue Type: New Feature > Components: Scheduler >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek > Fix For: 0.6 > > > includes: > - support of any scheduler which allows to register jobs based on > cron-expressions > - default integration with quartz -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (DELTASPIKE-399) Incorporate Solder's ResourceLoader features into DeltaSpike
[
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)
[jira] [Commented] (DELTASPIKE-399) Incorporate Solder's ResourceLoader features into DeltaSpike
[
https://issues.apache.org/jira/browse/DELTASPIKE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13855077#comment-13855077
]
John D. Ament commented on DELTASPIKE-399:
--
[~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)
[jira] [Commented] (DELTASPIKE-472) Implement portable extensions that install custom beans when not running inside a WAR file.
[ https://issues.apache.org/jira/browse/DELTASPIKE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13855058#comment-13855058 ] John D. Ament commented on DELTASPIKE-472: -- It's implicitly agreed upon with the agreement to add module.xml files. > Implement portable extensions that install custom beans when not running > inside a WAR file. > --- > > Key: DELTASPIKE-472 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-472 > Project: DeltaSpike > Issue Type: Improvement > Components: Core >Reporter: John D. Ament >Assignee: John D. Ament > Fix For: 0.6 > > > In many cases, when you deploy with CDI you're using a self contained WAR > that has everything in it. However, in certain deployment models you can > reference external classpath entries that could be available to you, but not > scanned based on CDI scanning rules. > To work with these more efficiently, we need to implement some extensions > that do very basic things, mostly installing custom beans at runtime to the > destination applications. > I'll go through the application and identify cases where we need to install a > bean, ignoring things that obviously don't belong, e.g. @Typed classes which > are understood to not be installed. At a minimum we should create extensions > that encompass our primary features, where they don't already exist - for > example, Partial Bean is already an extension and needs no other work, Bean > Validation doesn't need an extension since it can be configured, Servlet > simply needs to be registered. Most of this work seems to be in Core. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Reopened] (DELTASPIKE-475) auto. registration of jobs with cron-expressions
[ https://issues.apache.org/jira/browse/DELTASPIKE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John D. Ament reopened DELTASPIKE-475: -- > auto. registration of jobs with cron-expressions > > > Key: DELTASPIKE-475 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-475 > Project: DeltaSpike > Issue Type: New Feature > Components: Scheduler >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek > Fix For: 0.6 > > > includes: > - support of any scheduler which allows to register jobs based on > cron-expressions > - default integration with quartz -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-475) auto. registration of jobs with cron-expressions
[ https://issues.apache.org/jira/browse/DELTASPIKE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13855057#comment-13855057 ] John D. Ament commented on DELTASPIKE-475: -- -1 If we're going to support multiple impls, we need to have an impl-quartz module, to allow us to have other impls in place. > auto. registration of jobs with cron-expressions > > > Key: DELTASPIKE-475 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-475 > Project: DeltaSpike > Issue Type: New Feature > Components: Scheduler >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek > Fix For: 0.6 > > > includes: > - support of any scheduler which allows to register jobs based on > cron-expressions > - default integration with quartz -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (DELTASPIKE-478) Create build profile in jenkins that creates binary distribution.
John D. Ament created DELTASPIKE-478: Summary: Create build profile in jenkins that creates binary distribution. Key: DELTASPIKE-478 URL: https://issues.apache.org/jira/browse/DELTASPIKE-478 Project: DeltaSpike Issue Type: Improvement Affects Versions: 0.6 Reporter: John D. Ament Assignee: Mark Struberg Priority: Minor Please add a jenkins job to execute with the -Pdistribution profile. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (DELTASPIKE-477) New Scheduler module is not included in binary distribution.
John D. Ament created DELTASPIKE-477: Summary: New Scheduler module is not included in binary distribution. Key: DELTASPIKE-477 URL: https://issues.apache.org/jira/browse/DELTASPIKE-477 Project: DeltaSpike Issue Type: Bug Components: Scheduler Reporter: John D. Ament -- This message was sent by Atlassian JIRA (v6.1.5#6160)
