I need advice on writing the aspectj expression to find all classes with the class name pattern.
Below is the expression I have now to capture the method servletImplementation() from the main package flow. I would like to tweak it more to do weaving only on the classes that has name ends with *Log. Any suggestions on how to do this?
#After("execution(* flow..servletImplementation(..))")
I think the asterisk wildcard should work just fine for you:
Classes starting 'flow':
#After("execution(* flow*.servletImplementation(..))")
Classes with names starting Foo somewhere below a root package of flow:
#After("execution(* flow..Foo*.servletImplementation(..))")
Related
Can I control which classes are included when I use -generateJsInteropExports?
I'm finding that when I use the flag, the JS output includes a bunch of classes that I'm not using in the project, but whose source appears in some of the packages I'm using. I don't want these classes to be included in the output. Normally, GWT does a good job of only bringing in classes that I'm actually using.
How can I tell the compiler "in this compilation I'd like you to generate JsInterop for these classes, but not these"?
I found these GWT compiler options:
-includeJsInteropExports/excludeJsInteropExports
Include/exclude members and classes while generating JsInterop exports. Flag could be set multiple times to expand the pattern. (The flag has only effect if exporting is enabled via -generateJsInteropExports)
But I couldn't seem to get them to work. I tried using:
-generateJsInteropExports
-includeJsInteropExports com.example.MyClass
The class wasn't included.
The filtering is at the level of class member (i.e. fields and methods) rather than type name. To match all members of a class the syntax is:
-generateJsInteropExports
-includeJsInteropExports com.example.MyClass.*
Note: It's a regular expression, so the dots represent "any character" rather than periods. You'd have to escape them if there were ambiguity.
"The ambiguity, is in the box" - Monty Python.
Autofac is having a problem resolving an interface. See attached solution.
The Interface, IAmbiguous, is defined in project ACommon. It is implemented in project AInjectable. The AInjectable project does not / cannot reference ACommon. The AInjectable project defines IAmbiguous as an existing item brought in with a file link.
The UI project calls ACommon Inject and attempts to register the AInjectable assembly. IAmbiguous is not ambiguous initially but after a builder.RegisterAssemblyTypes command it becomes "ambiguous in the namespace." There is no error thrown when the container is built but the registration is not there.
Registration can be done "AsImplementedInterfaces" if Named and Keyed is not used. But then there is no way to Resolve the registration because the service IAmbiguous is "ambiguous in the namespace."
This question was double-posted as an issue on Autofac. It is not an Autofac problem. I will copy/paste the answer from the issue in here; for future readers, if you want to see the repro solution, go check out the full issue
What you're doing by including the same interface in two different assemblies isn't something you should be doing. Note that by doing that, your AInjectable class is not implementing the interface from the ACommon project. It's implementing a different but identically named interface.
This sort of thing is a problem - having the same type (interface, class, whatever) name in two different assemblies. We even had a problem (#782) where we had a System.SerializableAttribute in Autofac as a shim for .NET Core. You really just can't do that.
You'll also see the same thing if you try to make a static extension method class that has the same namespace and name as some other static extension method class. Ambiguous references.
Without doing Reflection.Emit style code generation, you won't be able to declare an interface in one assembly ("Assembly A") and implement that interface in a different assembly ("Assembly B") without having Assembly B reference Assembly A. That's just how .NET works. What you're seeing is a manifestation of that when you use Autofac, but it's not caused by Autofac. It's caused by you doing something you shouldn't be doing in .NET.
The fix is to define your interfaces in a separate assembly that everyone implementing the interfaces can reference. (Or you can try to dynamically generate code using Reflection.Emit or Roslyn or something, but that's waaaay harder.)
After reading multiple style guides and trying to not use inheritance in my node definitions (as suggested by puppet labs), I would like to know what the common way of including classes in puppet without using inheritance.
I have been trying the following with my node definitions, but it does not seem to work:
# in module 'baseclass'
# baseclass.pp
class baseclass {
include xclass
include yclass
include zclass
}
# servernode01.pp
node 'servernode01' {
include baseclass
}
where xclass, yclass and zclass are funcitonal puppet classes and including them in the node servernode01 produces the desired state (i.e. the resources are applied to the node).
My question(s) are:
Is including classes in classes a good alternative to inheritance?
Are there some issues in the methodology I am using as an alternative to inheritance?
I ask my second question since it seems the nodes that include baseclass do not receive the resources defined in xclass, yclass and zclass.
My ultimate goal is to have a base class that will implement the minimum requirements which I specify.
yes, composition is better than inheritance in Puppet
your example should work fine
An alternative to include baseclass is class { 'baseclass': }. You need the latter if you want to use parameters, and also have into account that you can use include multiple times but not the class syntax, as puppet will complain with duplicate class definition.
The official puppet docs state clearly that inheritance should be used only really "sparingly". They actually name exactly two situations where this should happen:
when you want to overwrite a parmeter of a resource defined in the parent class
when you want to inherit from a parameters class for standard parameter values
see http://bit.ly/1r1RO0K
So yes, this is clearly better, even with official blessing :)
I have a use case where I need to create a class based on user input.
For example, the user input could be : "(Int,fieldname1) : (String,fieldname2) : .. etc"
Then a class has to be created as follows at runtime
Class Some
{
Int fieldname1
String fieldname2
..so..on..
}
Is this something that Scala supports? Any help is really appreciated.
Your scenario doesn't seem to make sense. It's not so much an issue of runtime instantiation (the JVM can certainly do this with reflection). Really, what you're asking is to dynamically generate a class, which is only useful if your code makes use of it later on. But how can your code make use of it later on if you don't know what it looks like? For example, how would your later code know which fields it could reference?
No, not really.
The idea of a class is to define a type that can be checked at compile time. You see, creating it at runtime would somewhat contradict that.
You might want to store the user input in a different way, e.g. a map.
What are you trying to achieve by creating a class at runtime?
I think this makes sense, as long as you are using your "data model" in a generic manner.
Will this approach work here? Depends.
If your data coming from a file that is read at runtime but available at compile time, then you're in luck and type-safety will be maintained. In fact, you will have two options.
Split your project into two:
In the first run, read the file and write the new source
programmatically (as Strings, or better, with Treehugger).
In the second run, compile your generated class with the rest of your project and use it normally.
If #1 is too "manual", then use Macro Annotations. The idea here is that the main sub-project's compile time follows the macro sub-project's runtime. Therefore, if we provide the main sub-project with an "empty" class, members can be added to it dynamically at compile time using data that the macro sees at runtime. - To get started, Modify the macro to read from a file in this example
Else, if you're data are truly only knowable at runtime, then #Rob Starling's suggestion may work for you as it did me. I'll share my attempt if you want to be a guinea pig. For debugging, I've got an App.scala in there that shows how to pass strings to a runtime class generator and access it at runtime with Java reflection, even define a Scala type alias with it. So the question is, will your new dynamic class serve as a type-parameter in Slick, or fail to, as it sometimes does with other libraries?
I have an assignment to code several methods in Scala. The methods will be encapsulated in an object that has no main method. The professor gave us a JAR file that contains an interface (my object implements this interface) as well as a sort of pseudo test object that performs various assert statements against each of my functions. This object also does not contain a main method.
Now in Intellij I simply had to declare the dependency on the JAR in the classpath, and it runs fine. Eclipse is giving me trouble though because when I go to define a Scala application run configuration it specifically asks me to name the class that contains a main method, and there is no main method.
I am assuming that I might be choosing the wrong project type for this type of set up, but I am inexperienced with this and I would appreciate any advice you might have for running something like this in eclipse.
Thanks.
I would either:
just write an object with a main method which calls the test object, or
start a Scala interpreter in your project (from context menu, under Scala).
Preferring the first approach, because it's faster to repeat tests after a modification.