[JBoss JIRA] (FORGE-801) Support for Transactional Resources
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-801?page=com.atlassian.jira.plugin.... ]
George Gastaldi updated FORGE-801:
----------------------------------
Fix Version/s: 2.0.0.Alpha5
(was: 2.0.0.Alpha4)
> Support for Transactional Resources
> ------------------------------------
>
> Key: FORGE-801
> URL: https://issues.jboss.org/browse/FORGE-801
> Project: Forge
> Issue Type: Feature Request
> Components: Resources API
> Affects Versions: 1.2.1.Final
> Reporter: George Gastaldi
> Assignee: George Gastaldi
> Priority: Critical
> Fix For: 2.0.0.Alpha5
>
> Attachments: IMG_20130225_215814.jpg, UserGuide_TXFileInJava_v1.0.pdf
>
>
> FileResources should be transactional, that is, allow modification of resources for displaying purposes and allow commit or rollback of changes.
> The implementation could copy the modified file to a temporary folder and when commit is invoked, copy back the contents to the original folder.
> It may be necessary to provide a pointer back to the original file (Properties file next to changed file maybe?).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (FORGE-802) Support multiple select/pick-up/cd Resources
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-802?page=com.atlassian.jira.plugin.... ]
George Gastaldi updated FORGE-802:
----------------------------------
Fix Version/s: 2.0.0.Alpha5
(was: 2.0.0.Alpha4)
> Support multiple select/pick-up/cd Resources
> --------------------------------------------
>
> Key: FORGE-802
> URL: https://issues.jboss.org/browse/FORGE-802
> Project: Forge
> Issue Type: Feature Request
> Components: UI - Shell
> Reporter: Lincoln Baxter III
> Fix For: 2.0.0.Alpha5
>
>
> {code}/home/lincoln/projects/forge/*.java/get* [2432 selected] ${code}
> (04:17:31 PM) lincolnthree1: i was thinking it would be nice if the cd or "select" or "pick up" command accepted wildcards/filters of some sort
> (04:17:44 PM) lincolnthree1: obviously *.java works, but only in the current directory/resource
> (04:17:46 PM) lincolnthree1: so
> (04:17:54 PM) lincolnthree1: 'cd *.java' would select all the
> (04:18:00 PM) lincolnthree1: java files in the current dir
> (04:18:07 PM) lincolnthree1: but it would be really nice if you could do something like:
> (04:18:20 PM) lincolnthree1: select **/*.java
> (04:18:27 PM) lincolnthree1: or select *.java -r
> (04:18:32 PM) lincolnthree1: select -r *.java
> (04:18:40 PM) lincolnthree1: and recursively select resources
> (04:18:50 PM) lincolnthree1: from . onward
> (04:20:39 PM) stalep: sure that should work. but what do you mean by "select". selected for what?
> (04:21:11 PM) lincolnthree1: UIContext.getInitialSelection()
> (04:21:18 PM) lincolnthree1: multi-cd
> (04:22:00 PM) stalep: im my head cd is change directory, so sorry for being a bit slow with the context switching :)
> (04:22:21 PM) lincolnthree1: think of this as an advanced for of CD
> (04:22:28 PM) lincolnthree1: imagine this:
> (04:22:31 PM) lincolnthree1: cd *.java
> (04:22:34 PM) gegastaldi: pick-up might be more like it
> (04:22:38 PM) lincolnthree1: [12 java files in context]
> (04:22:43 PM) mmatloka: gegastaldi: are you ready?:P
> (04:22:50 PM) lincolnthree1: ls .
> (04:22:54 PM) gercan [~gorkem(a)217.131.48.21] entered the room.
> (04:23:03 PM) lincolnthree1: now prints out all the fields/methods of the 12 java files
> (04:23:11 PM) gegastaldi: mmatloka: for what ? Pull requests ? :)
> (04:23:13 PM) lincolnthree1: rm . would delete all 12 java files
> (04:23:18 PM) stalep: ok
> (04:23:26 PM) mmatloka: gegastaldi: for learning :D
> (04:23:27 PM) jamezp_afk is now known as jamezp
> (04:23:32 PM) lincolnthree1: so it's like "cd++"
> (04:23:41 PM) lincolnthree1: taking 'cd' to the next level
> (04:24:23 PM) stalep: so its not a cd, but more of a select as you mentioned earlier
> (04:24:39 PM) gegastaldi: cr
> (04:24:41 PM) lincolnthree1: basically
> (04:24:44 PM) gegastaldi: Select resource
> (04:24:45 PM) stalep: co cd *.java will select all methods on all java files?
> (04:24:51 PM) lincolnthree1: well
> (04:24:58 PM) lincolnthree1: cd *.java would select all java files in the current dir
> (04:25:02 PM) lincolnthree1: once you've done that
> (04:25:07 PM) lincolnthree1: you could then cd get*
> (04:25:15 PM) lincolnthree1: which would select all getters in all java files in the current directory
> (04:25:48 PM) lincolnthree1: so 'cd *.java/get*' would be the equivalent single command
> (04:25:57 PM) stalep: ok
> (04:26:07 PM) Cojan [~cvanball@2001:980:92c0:1:2677:3ff:fe7d:2620] entered the room.
> (04:26:20 PM) gegastaldi: Oh, cd as in Change Destination, not Change Directory :)
> (04:26:35 PM) lincolnthree1: then issuing an 'rm' would delete all those selected getters and drop you back to a selection of just the *.java files
> (04:27:04 PM) lincolnthree1: similarly, I guess you could do:
> (04:27:08 PM) lincolnthree1: rm *.java/get*
> (04:27:27 PM) lincolnthree1: and just imagine if autocomplete worked here
> (04:27:34 PM) lincolnthree1: serious shell power
> (04:28:26 PM) gegastaldi: There should be a way to display the selected resources in the command prompt also
> (04:28:37 PM) lincolnthree1: right
> (04:28:43 PM) lincolnthree1: so the prompt would probably say something like:
> (04:29:22 PM) lincolnthree1: /home/lincoln/projects/forge/[*.java/get*] 12 selected $
> (04:29:33 PM) lincolnthree1: actually it would probably be something like:
> (04:29:42 PM) lincolnthree1: /home/lincoln/projects/forge/[*.java/get*] 2432 selected $
> (04:29:45 PM) lincolnthree1: lol
> (04:29:50 PM) gegastaldi: Lol
> (04:30:07 PM) gegastaldi: I like the idea
> (04:30:25 PM) gegastaldi: But
> (04:30:27 PM) lincolnthree1: or maybe
> (04:30:36 PM) lincolnthree1: /home/lincoln/projects/forge/*.java/get* [2432 selected] $
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (FORGE-876) Cannot @Inject UIInput<FileResource<?>> input; Deployment exception results.
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-876?page=com.atlassian.jira.plugin.... ]
George Gastaldi updated FORGE-876:
----------------------------------
Fix Version/s: 2.0.0.Alpha5
(was: 2.0.0.Alpha4)
> Cannot @Inject UIInput<FileResource<?>> input; Deployment exception results.
> ----------------------------------------------------------------------------
>
> Key: FORGE-876
> URL: https://issues.jboss.org/browse/FORGE-876
> Project: Forge
> Issue Type: Bug
> Components: Container, Plugin API
> Affects Versions: 2.0.0.Alpha2
> Reporter: Lincoln Baxter III
> Fix For: 2.0.0.Alpha5
>
>
> {code}
> org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [UIInput<FileResource<Object>>] with qualifiers [@Service] at injection point [[BackedAnnotatedField] @Inject org.jboss.forge.ui.impl.UIInputResourceInjectionTest.firstName]
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:403)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:325)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:177)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:208)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:519)
> at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:505)
> at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:480)
> at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536)
> at org.jboss.weld.bootstrap.api.helpers.ForwardingBootstrap.validateBeans(ForwardingBootstrap.java:75)
> at org.jboss.weld.environment.se.Weld.initialize(Weld.java:138)
> at org.jboss.forge.container.impl.AddonRunnable$AddonContainerStartup.call(AddonRunnable.java:171)
> at org.jboss.forge.container.impl.AddonRunnable$AddonContainerStartup.call(AddonRunnable.java:133)
> at org.jboss.forge.container.util.ClassLoaders.executeIn(ClassLoaders.java:34)
> at org.jboss.forge.container.impl.AddonRunnable$3.call(AddonRunnable.java:106)
> at org.jboss.forge.container.impl.AddonRunnable$3.call(AddonRunnable.java:98)
> at org.jboss.forge.container.LockManagerImpl.performLocked(LockManagerImpl.java:48)
> at org.jboss.forge.container.impl.AddonRunnable.run(AddonRunnable.java:97)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:680)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (FORGE-886) Should be able to re-install an existing Addon if it is a SNAPSHOT
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-886?page=com.atlassian.jira.plugin.... ]
George Gastaldi updated FORGE-886:
----------------------------------
Fix Version/s: 2.0.0.Alpha5
(was: 2.0.0.Alpha4)
> Should be able to re-install an existing Addon if it is a SNAPSHOT
> ------------------------------------------------------------------
>
> Key: FORGE-886
> URL: https://issues.jboss.org/browse/FORGE-886
> Project: Forge
> Issue Type: Story
> Components: Container, Plugin Repository
> Affects Versions: 2.0.0.Alpha3
> Reporter: Lincoln Baxter III
> Fix For: 2.0.0.Alpha5
>
>
> Currently re-installing Addons is not supported, because there is no way to tell Forge to stop using the existing deployed files without giving it time to detect the change and re-deploy the addon.
> In order to implement this, the Forge registry file probably needs to use some kind of marker files.
> {code}
> .dodeploy
> .deployed
> .undeployed
> {code}
> So that it knows how to respond when changes are made faster than timestamps can detect. This would (hopefully) also in theory be a step toward multi JVM (multiple running forge / concurrent modification instance) support.
> This has been partially implemented, but only naively. The files are actually re-written on UNIX based OS's, and will be re-loaded next time the addon is disabled/re-enabled, but this will not work on Windows.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months