WindupRuleMetadata
by Ondrej Zizka
Hi,
1) WindupRuleMetadata should IMO be named RuleProvidersRegistry.
2) WindupRuleMetadata has:
private final List<WindupRuleProvider> providers = new ArrayList<>();
private final IdentityHashMap<WindupRuleProvider, List<Rule>>
providersToRules = new IdentityHashMap<>();
private Configuration configuration;
Isn't the first redundant? It can be acquired simply by
providersToRules.getKeys().
And WRT configuration - that one only has
public List<Rule> getRules();
Is that another redundancy, since rules are in the map? It could be
retrieved as merge of getValues().
Ondra
10 years, 7 months
Windup 2.2.0.Final Release Date - 17/Mar/2015
by Lincoln Baxter, III
I checked the project calendar and we are on schedule for a 17/Mar/2015
release of 2.2.0.Final
The primary goal of this release (among other things), is enablement of
rule-set storage, categorization, and selection.
More updates tomorrow during the weekly meeting.
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
10 years, 7 months
RuleProvider's and Rule's metadata
by Ondrej Zizka
Hi all,
I am working on the categories.
I think we all agree that this should have a nice API since every rule
will work with that, directly or indirectly.
We will get more metadata, and "hiding" them into various places,
untyped hashmaps of lists of strings, really seems like a bad way to do it.
After some work on the subject, I think we should abandon the current
unfortunate approach of Rules acting like a map through being a Rule and
Context at the same time, needing conditional retyping. And the other
way of overriding methods like enhanceMetadata() is not fortunate either
as every subclass needs to be aware of what's going on in the superclasses.
Instead, we should follow the *conventions*, take the *standard*
approach, and let Rules have a normal getMetadata(), which would return
an object with all the metadata at one place. This could be subclassed
to match the needs of individual addons but provide type-safe and
easy-to-use API for shared metadata.
getPhase(), getExecute*(), getCategories() etc. could
a) still return what they return, being executed by the loader as now,
and put to that object, or
b) let the rule initialize this object in rule's init() (which we don't
have) or a construtor;
I would drop get*() but we could tunel them to that object for
backwards compatibility.
I think this goes beyond the scope of Windup and would need a rewrite of
Rewrite (well, not real rewrite, but I liked the pun :).
Other option is to keep scattering metadata in various places, untyped
hashmaps of lists of strings. Not recommended.
WDYT?
Ondra
10 years, 7 months
Re: [windup-dev] Windup 2.1.0.Final - EAP 6.x integration (Windup-as-a-Service)
by Lincoln Baxter, III
Hey Marc,
(Copying Windup dev so everyone can see what's going on - the are some
valuable examples here.)
First, I didn't see anything borrowed from George's project other than
possibly some config in the POM (which created some duplicate dependencies
and included a LOT of stuff you don't need.) I've gone ahead and updated
the project for you and hosted it within the Windup organization. *You can
find the code here:*
https://github.com/windup/windup-web
*To run the example*, you will need to *first update the path here* to
point to your local project directory (where the project is checked out.)
If the server is not doing exploded deployments, this should be updated to
actually extract the addon-repository from WEB-INF/addon-repository to a
temp directory and point to that temp directory (I'll leave that to you, if
necessary):
https://github.com/windup/windup-web/blob/master/src/main/java/org/jboss/...
*Then run a build:*
mvn clean install
*Now deploy the application and run it *on EAP6.2+ - you can execute Windup
via the REST endpoint (make sure to update the URL to the right local
paths) :
http://192.168.1.6:8080/windup-web/rest/windup?inputPath=....../projects/...
*The web service endpoint code is here:*
https://github.com/windup/windup-web/blob/master/src/main/java/org/jboss/...
I've also updated the server.log so you can see the output from my test
execution on my local machine. Everything ran successfully and the report
was generated :)
I hope this helps,
Lincoln
On Sun, Mar 1, 2015 at 5:48 PM, Marc Zottner <mzottner(a)redhat.com> wrote:
> Hi Lincoln!
>
> Last Wednesday I spent a couple of hours trying to run Windup 2.1.0.Final
> on EAP 6 without success. I started from scratch using the example of
> Georges that you mentioned. The example itself worked very well. As soon as
> I bound the windup libraries / add-ons, I had several issues.
>
> Here is the latest exception I was not able to fix:
>
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408
> Unsatisfied dependencies for type [AddonRegistry] with qualifiers
> [@Default] at injection point [[parameter 3] of [method] public
> org.jboss.windup.config.furnace.FurnaceHolder.setFurnace(PostStartup,
> Furnace, AddonRegistry)]
> at
> org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:315)
> at
> org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:284)
> at
> org.jboss.weld.bootstrap.Validator.validateObserverMethods(Validator.java:560)
> at
> org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:376)
> at
> org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:379)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:64)
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980)
> [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913)
> [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> ... 3 more
>
> (cf. https://github.com/Maarc/forge-rest-service/blob/master/server.log)
>
> Do you know what could be the issue here? I checked the project in
> https://github.com/Maarc/forge-rest-service/.
> <https://github.com/Maarc/forge-rest-service/>
>
> best regards and have a great start in your week,
>
> Marc
>
>
>
>
>
>
>
>
>
> ------------------------------
> *Von: *"Lincoln Baxter, III" <lincolnbaxter(a)gmail.com>
> *An: *"Marc Zottner" <mzottner(a)redhat.com>
> *Gesendet: *Mittwoch, 25. Februar 2015 17:32:41
> *Betreff: *Re: Fw: Windup 2.1.0.Final - EAP 6.x integration
> (Windup-as-a-Service)
>
>
> Hey Marc,
>
> I'm trying to figure out what exactly you are trying to do here. It looks
> like you are somehow attempting to deploy Windup as a JBoss Module? That
> definitely won't work. (I can explain why if you are really interested, but
> basically Windup runs inside Furnace, and the way you've wired things up,
> you're not running it inside Furnace. https://github.com/forge/furnace)
>
> You need to embed Windup by doing something like this:
>
> https://github.com/windup/windup/blob/master/bootstrap/src/main/java/org/...
>
> That means you'll need to install windup into your application via the
> furnace-maven-plugin and probably unzip that folder from the WAR to a
> folder on disk at startup (for offline use):
> https://github.com/windup/windup/blob/master/dist/pom.xml#L28
>
> Alternatively if you want to depend on an internet connection, you can do
> this at runtime:
> https://github.com/forge/furnace#usage
>
> I hope this helps,
> ~Lincoln
>
>
> On Wed, Feb 25, 2015 at 6:11 AM, Marc Zottner <mzottner(a)redhat.com> wrote:
>
>> Hi Lincoln!
>>
>> I am quite far with the integration of windup 2 and EAP. However I am
>> getting something like that:
>>
>> ______
>>
>> 11:42:04,894 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-13)
>> MSC000001: Failed to start service
>> jboss.deployment.unit."winddrop.ear".WeldStartService:
>> org.jboss.msc.service.StartException in service
>> jboss.deployment.unit."winddrop.ear".WeldStartService: Failed to start
>> service
>> at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1936)
>> [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> [rt.jar:1.7.0_71]
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> [rt.jar:1.7.0_71]
>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71]
>> Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List
>> with 1 exceptions:
>> Exception 0 :
>> java.lang.IllegalArgumentException: Coordinates must be of the form
>> 'name,version' or 'name,version,api-version
>> at org.jboss.forge.furnace.addons.AddonId.fromCoordinates(AddonId.java:78)
>> at
>> org.jboss.forge.addon.ui.impl.extension.AnnotatedCommandExtension.observeAnnotationMethods(AnnotatedCommandExtension.java:33)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:606)
>> at
>> org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:267)
>> at
>> org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
>> at
>> org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
>> at
>> org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263)
>> at
>> org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:164)
>> at
>> org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
>> at
>> org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
>> at
>> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:245)
>> at
>> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:233)
>> at
>> org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:213)
>> at
>> org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:117)
>> at
>> org.jboss.weld.event.TransactionalObserverNotifier.notifyObserver(TransactionalObserverNotifier.java:44)
>> at
>> org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:85)
>> at
>> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:75)
>> at
>> org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:60)
>> at
>> org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:38)
>> at
>> org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.fire(ProcessAnnotatedTypeImpl.java:41)
>> at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:83)
>> at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:137)
>> at
>> org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184)
>> at
>> org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349)
>> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:63)
>> at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980)
>> at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> at java.lang.Thread.run(Thread.java:745)
>>
>> at
>> org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:40)
>> at
>> org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.fire(ProcessAnnotatedTypeImpl.java:41)
>> at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:83)
>> at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:137)
>> at
>> org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184)
>> at
>> org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349)
>> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:63)
>> at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980)
>> [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
>> at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913)
>> [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
>> ... 3 more
>> ______
>>
>>
>> Attached you will find my module.xml and I am starting EAP passing the
>> following parameters:
>>
>> /bin/standalone.sh -c standalone-full.xml
>> -Dcom.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true
>> -Dforge.standalone=true
>> -Dforge.home=/opt/jboss/jboss-eap-6.3/modules/system/layers/base/org/jboss/windup/2.1.0.Final
>> -Dwindup.home=/opt/jboss/jboss-eap-6.3/modules/system/layers/base/org/jboss/windup/2.1.0.Final
>>
>>
>> Do you have any idea what could be wrong or missing?
>>
>>
>> best regards,
>>
>> Marc
>>
>>
>>
>>
>>
>> On 25 Feb 2015 at 11:59:40, Marc Zottner (mzottner(a)redhat.com) wrote:
>>
>>
>> Hi everyone,
>>
>> I hope you are doing great. Yesterday I had a look at the latest version
>> of Windup (2.1.0.Final) and I really like it :) It seem way faster than the
>> previous releases I tested.
>>
>>
>> Yesterday I updated the windup-as-a-service fronted (
>> https://github.com/Maarc/windup-as-a-service), made some cleanup and
>> fixed issues with chrome. It is basically an EAP 6 web application running
>> windup 0.7. During the last weeks, I installed this in combination with
>> custom rules for a customer having hundreds of developers. Do not hesitate
>> to have a look at it and give me some feedback.
>>
>>
>> I started to integrated the windup-as-a-service fronted with Windup
>> 2.1.0.Final and would be glad to have your support.
>>
>>
>> *BUILD*
>>
>> In order to be able to build Windup 2.1.0.Final, I had to
>>
>> - add <skipTests>true</skipTests> to the grand-father-pom
>> - import manually “indexer-core-6.0.WINDUP.jar” in my local
>> repository from the standalone/offline build (
>> https://repository.jboss.org/nexus/content/repositories/releases/org/jbos...
>> )
>> - add the "
>> https://repository.jboss.org/nexus/content/repositories/releases”
>> maven repository to my dependencies
>>
>> It would be great to document it.
>>
>> However my built client in the “dist” directory has less jars than in the
>> "windup-distribution-2.1.0.A-offline.zip” and I was not able to run it.
>>
>>
>> *INTEGRATION in EAP 6.x*
>>
>> In order to integrate Windup 2.1.0.Final in EAP, I tried to follow the
>> same way that worked for windup 0.7:
>> - define a custom jboss-module containing most of the windup and add ons
>> libraries (expected the weld ones)
>> - control the loaded dependencies with a custom
>> jboss-deployment-structure.xml
>>
>> So far it does not work and I am not sure this approach is really a good
>> idea. Forge has not been designed to be executed in EAP 6 directly. Do you
>> have some hints for doing this?
>>
>>
>> Maybe using a java wrapper and calling the standalone windup installation
>> would be a better idea ...
>>
>>
>> best regards,
>>
>> Marc
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
10 years, 7 months
Unclassified files
by Samuel Tauil
Hi,
I understand the Unclassified Files section in the report as a list of all files which were decompiled properly by Procyon but weren't captured by any rules, so the user can check and see which resources need to be checked again and generate specific rules or not. Is that correct?
Thanks
Samuel
10 years, 7 months
