I'm trying to create a fiddler Inspector2 and IFiddlerExtension in the same assembly. However, I can't get the extension to load if I host the assembly in the /Fiddler2/Inspectors/ folder and the inspector won't load when hosted in the /Fiddler2/Scripts assembly. Alternately, is there a way to manually inject, let's say, the inspector in the OnLoad code in the extension (or vice versa)?
I suspect the answer is no, but does someone know if it is possible to get Fiddler to load both types from the same assembly?
Background:
I'd like to be able to provide an inspector that will provide some visualization of a given response, while an extension hosts a new tab that will configure and provide analysis over the entire set of sessions.
If I need separate assemblies, I will likely need three since I'll have common code factored into a shared assembly and then the two assemblies to be put in different locations. It's a lot of extra work for a small assembly with only a handful of types.
You're correct to note that Fiddler's partitioning of extension types makes it difficult to offer both FiddlerExtensions and Inspectors in a single assembly today.
Technically, there's nothing stopping your Inspector object from manually creating and managing a top-level tab, since the primary point of the IFiddlerExtension interface is to get your code loaded in the first place, and Inspectors are already loaded anyway.
In the future, this could conceivably be problematic as I hope to offer "delay-loaded" extension types, but that feature would almost certainly be opt-in and thus not likely to break you.
Related
Yes, I'm beginner. and I used Webstorm but now using Vscode.
I know to say 'extension' in Vscode.
But sometimes to say 'plugin' in Vscode.(ex. Do you know Vscode's Prettier plugin?)
Can others understand this?
I understand it like this Python's pip and Node's npm to understand.
Just different name.
Is that what I understand right?
There is very thin border line between the two.
Extension and plugins often confused people. And Mostly people believe both are same.
The main difference between the two is that plug-in provides extra functionality which does not modify the core functionality.
While extension is made for modifying core functionality, may be provided due to version change or improvement.
Securing plugins is more complex than extension.
Extension are individual identity so one extension needs one set of privileges, whereas plugins are more complicated and needs to identify privileges for each application runs plugins rather than a whole plugin.
Extension is specific to particular application. It extends functionality of a particular application or software.
While plug-in can be made generalized which may runs independently in coordination with particular application or software.
Is there a generic way to prevent a given set of files from being parsed by IntelliSense modules while it still shows up elsewhere?
For instance, I have a third-party library that provides an AppModel class I can customise. Such class is defined in several places:
The library bundles a template to copy from.
The library includes a usage example.
The library implements the class in a helper tool.
The library defines the class for its test harness.
I implement the class in my app.
My implementation is the only one that gets loaded when the app runs and the only one I care about when I navigate my code or use Go to Symbol yet I need to pick among the 5 definitions every time.
For languages where there isn't a specific setting, the only way to go appears to be files.exclude. But that directive basically makes the file or directory completely disappear from the program. It won't even show up in the Explorer pane. That feature seems designed for source control metadata and similar stuff and I don't think it's entirely convenient for third-party libraries.
Any idea?
Considering that I am developing an end-user software program (as an uberjar) I am wondering what my options are to make it possible for the user to download a plugin and load that during runtime.
The plugin(s) should come compiled and without source code, so sth. like load is not an option.
What existing libraries (or ways of Java...?) exist to build this on?
EDIT: If you are not sure I would also be satisfied with a way that costs a reboot/-start of the main-program. However, what is important is that the source-code won't be included in any JAR file (neither main application nor plugin-jars, see :omit-source of Leiningen documentation).
To add a jar during runtime, use pomegranate which lets you add a .jar file to the classpath. Plugins of your software should be regular Clojure libs that follow certain conventions that you need to establish:
Make them provide (e. g. in an edn) a symbol to an object implementing a constructor/destructor mechanism such as the Lifecycle protocol in Stuart Sierras component library. In runtime, require and resolve that symbol, start the resulting object and hand it over to rest your programs plugin coordination facilities.
Provide a public API in your program that allows the plugins to interact with it in ways that you coordinate asynchronously e. g. with clojure.core.async (don't let one plugin block the entire program).
Make sure that the plugins have a coordinated way to expose their functionality to each other only if they desire so to enable a high degree of modularity among your plugins. Make sure that your plugin loader is capable of detecting dependencies among plugins and is capable of loading and unloading them in the right order.
I've not tried it myself, but you should in theory be able to get OSGi to work with Clojure.
There's a Clojure / OSGi integration library here:
https://github.com/aav/clojure.osgi
If I were to attempt to role my own solution, I would try using tools.namespace to load and unload plugins. I'm not entirely sure it will work, but it's certainly in the right direction. I think one key piece is that the plugin jars will have to be "installed" in a location that's already on the classpath.
Again, this is only the start of one possible solution. I haven't tried doing this.
I'm trying to learn about Package interfaces and use access.
I have 2 hierarchies of packages
1:
ZAVG_TRAINING-PACKAGE1 containing
...
ZAVG_TRNG_SUBPKG3
2:
ZAVG_TRNGPKG_2_STRUCT_SUBPKG_1 containing
ZAVG_TRAINING_PACKAGE2 containing
ZAVG_TRNGPKG2_SUBKPG_1
In the first hierarchy, all the packages are not main packages.
In the second, the base package is a structure package, the next is a main package and the third is a non-main package.
In ZAVG_TRNG_SUBPKG3 (in the first hierarchy), I have a view ZAVG_V_MARA and a program ZAVG_DELETE_THIS_8. I also have a package interface exposing the program, and no use accesses granted.
My problem is that from a program contained in the package ZAVG_TRNGPKG2_SUBKPG_1 I can access both the objects contained in ZAVG_TRNG_SUBPKG3 with no restrictions.
As far as I see from the documentation, in order for a development object to be visible from packages outside the current package (except the outer package). I should have to add them all to the package interface and also create use accesses for the packages that should be allowed to use that interface.
What am I doing wrong?
As long as you're not planning to build something as complex as, let's say, the Enterprise Core Components, and planning to sell it to hundreds and thousands of anonymous customers who are in the mood of suing you if you change published interfaces, I wouldn't bother with the package access control. I know that doesn't answer your question, but all you'll end up with is a lot of wasted time and no advantages whatsoever. You'll have to tweak the package structure in illogical and really counter-intuitive to get things working.
In your case, there are quite a number of things that could have gone wrong - for example, the system-wide package checking switch might be turned off. Then, you'll have to remember that the checking only ever takes place at design time and never when running the program. Finally, as far as I remember, the check is not performed automatically - you'll have to execute it either manually or using some automated tool.
To manually check the package you can do it from the menu in the ABAP workbench:
Or by right-clicking on the object list:
However, as vwegert said: it is very likely that the package check is just not turned on in your system (I have not worked on a single system that had it turned on).
In order to provide nice URLs between parts of our app we split everything up into several modules which are compiled independently. For example, there is a "manager" portion and an "editor" portion. The editor launches in a new window. By doing this we can link to the editor directly:
/com.example.EditorApp?id=1
The EditorApp module just gets the value for id and loads up the document.
The problem with this is ALL of the code which is common between the two modules is duplicated in the output. This includes any static content (graphics), stylesheets, etc.
And another problem is the compile time to generate JavaScript is nearly double because we have some complex code shared between both modules which has to be processed twice.
Has anyone dealt with this? I'm considering scrapping the separate modules and merging it all back into one compile target. The only drawback is the URLs between our "apps" become something like:
/com.example.MainApp?mode=editor&id=1
Every window loads the main module, checks the value of the mode parameter, and and calls the the appropriate module init code.
I have built a few very large applications in GWT, and I find it best to split things up into modules, and move the common code into it's own area, like you've done. The reason in our case was simple, we had some parts of our application that were very different to the rest, so it made sense from a compile size point of view. Our application compiled down to 300kb for the main section, and about 25-40kb for other sections. Had we just put them all in one the user would have been left with a 600kb download, which for us was not acceptable.
It also makes more sense from a design and re-usability point of view to seperate things out as much as possible, as we have since re-used a lot of modules that we built on this project.
Compile time is not something you should generally worry about, because you can actually make it faster if you have seperate modules. We use ant to build our project, and we set it to only compile the GWT that has changed, and during development to only build for one browser, typical compile times on our project are 20 seconds, and we have a lot of code. You can see and example of this here.
One other minor thing: I assume you know that you don't have to use the default GWT paths that it generates? So instead of com.MyPackage.Package you could just put it into a folder with a nice name like 'ui' or something. Once compiled GWT doesn't care where you put it, and is not sensitive to path changes, because it all runs from the same directory.
From my experience building GWT apps, there's a few things to consider when deciding on whether you want multiple modules (with or without entry points), or all in one: download time (Javascript bundle size), compile time, navigation/url, and maintainability/re-usability.
...per download time, code splitting pretty much obviates the need to break into different modules for performance reasons.
...per compile time, even big apps are pretty quick to compile, but it might help breaking things up for huge apps.
...per navigation/url, it can be a pain to navigate from one module to another (assuming different EntryPoints), since each module has it's own client-side state...and navigation isn't seamless across modules.
...per maintainability/re-usability, it can be helpful from an organization/structure perspective to split into separate modules (even if there's only one EntryPoint).
I wrote a blog post about using GWT Modules, in case it helps.
Ok. I really get the sense there really is no "right" answer because projects vary so much. It's very much dependent on the nature of the application.
Our main build is composed of a number of in-house modules and 3rd party modules. They are all managed in seperate projects. That makes sense since they are used in different places.
But having more than one module in a single project designed to operate as one complete application seems to have overcomplicated things. The original reason for the two modules was to keep the URL simple when opening different screens in a new window. Even though had multiple build targets they all use a very large common subset of code (including a custom XML/POJO marshalling library).
About size... for us, one module was 280KB and the other was just over 300KB.
I just got finished merging everything back into one single module. The new combined module is around 380KB. So it's actually a bit less to download since most everyone would use both screens.
Also remember there is perfect caching, so that 380KB should only ever downloaded once, unless the app is changed.