I am writing and implementing some MIB files. I want to implement a bunch of objects in a Base-MIB and reuse it in multiple projects. One way is to copy Base-MIB for each project and then import mibs of each project to corresponding Base-MIB (as examples in Cisco MIBs that CISCOWORKS-MIB imports ciscoworks from CISCO-SMI and use it as parent of MODULE-IDENTITY). In this way I should set a different parent to MODULE-IDENTITY of each copy of Base-MIB and having 2 different instance of Base-MIB.
But I want to do it in a reverse manner. It means importing a Base-MIB in mibs of each project and then use defined objects in Base-MIB as a sub-tree with different OIDs and different implementation specific to each project (So different values). But i have problem to assign different OIDs to objects inside Base-MIB. I want to use exactly the same Base-MIB instance for both projects.
Is there any syntax or rule to achieve this task?
regards.
Related
Why do we use reverse domain name like com.something. or org.something. structure for java packages?
I understand this brings in some sort of uniqueness, but why do we need this uniqueness?
About why we do it reversed: Imagine you have two important packages, an accounting package and a graphics package. If you specified these in 'straight' order:
accounting.mycompany.org
graphics.mycompany.org
Then it implies there is a major accounting package, a subsection of which is for mycompany, and a subsection of that package is called the org package which you actually use. However, you want this:
org.mycompany.accounting
org.mycompany.graphics
This makes more sense. Out of all packages from organizations (org), you look at mycompany in particular, and it has two sub-packages, the accounting and the graphics ones.
Globally unique package names avoid naming collisions between libraries from different sources. Rather than creating a new central database of global names, the domain name registry is used. From the JLS:
The suggested convention for
generating unique package names is
merely a way to piggyback a package
naming convention on top of an
existing, widely known unique name
registry instead of having to create a
separate registry for package names.
As you say, reverse domain names as base package name ensures uniqueness. Suppose two companies with DN example.com and example.org both define the class Employee in their framework. Now if you are using both frameworks you will not be able pinpoint which Employee you want to use in your code, but if they are defined in packages com.example and org.example respectively you can tell the compiler/JVM specifically which class you are referring to. If unique packages are not defined you will get compilation errors or runtime errors, e.g. if you are using the com employee class, but the org employee class gets loaded first from the classpath you will get a runtime error, since the two employee classes may not have same structure.
The uniqueness is needed for Class Loading.
It helps by avoiding naming collisions. If there are classes with same package name and class name, Collision will occur while trying to load the classes.
This generally happens if there are multiple libraries(jar) that contain classes with same names.
Also see this.
You need the uniqueness if you might need to integrate your code with third party software, or provide it to someone else for integration. If you don't follow the rules, you increase the risk that at some point you will have a class naming collision, and that you will need to rename lots of your classes to address it. Or worse still, that your customers will have to do the code renaming.
This also applies when code is produces as part of different projects in an organization.
As you said, it brings uniqueness, something that is needed especially when working with third party code. For example, consider that you are using a library I've made. I've used the package "foo" and have a class named Bar there. Now if you are also using the package name "foo" AND you have a class named Bar, this would mean that your implementation would override my Bar implementation, making my implementation inaccessible. On the other hand, if my package were "com.mydomain.foo" and I'd had by Bar class there, then you can freely use the name Bar in one of your classes and both classes could still be uniquely identified and used separately.
Why use the reverse domain name as the package name? I guess that is just a convention to make sure that everybody uses a unique namespace, as you shouldn't use someone else's domain in your package name.
I have made a tournament system in Laravel 5.3.
Now I want to extract the core ( generating trees ) into a plugin, and make it open source.
The idea is doing the plugin, and then replace the code in my app with the plugin's code, and all the references.
I'm making a demo, so people can migrate an seed necessary objects to generate his own tournament tree.
My main concern is that in my system, I have a lot of thing that should not belong to the plugin, but they still are in the same tables.
In my models, I removed a lot of fields / functions that are not necessary in the plugin.
For instance, In my tournament model, I have a function that handle permission, because not all users can "crud" all tournaments. This function has no place in my plugin, as I will not include any policy ( this should up to each use case )
Another example should be printing the tree. In my system, I allow user to print the tree, but in my plugin is meant to be the core functions, not optional stuff.
Also, I think I should use only 1 model, I mean, I should delete my project model, and use my plugin model as they will represent the same data. So what if I remove a field / method as mentioned previously???
For my models, a solution should be that I create child object and just extend my plugins models, but it would mean change all my actual model names, is it a good approach???
How should I manage migration??? Should I include useless fields in my plugin?
Also, which User model should I use, Xoco\my-plugin\User, or App\User
I'd like to access attributes that are inside instances of defined types from other classes/instances.
This is very similar to a question asked on SO before - In Puppet, how can I access a variable/attribute inside a defined type?, however from what I understood the answer was specifically related to accessing parameters as opposed to arbitrary variables.
For example, given the following defined type:
define server (
$server_name = 'my_server'
){
$server_history = 'A long story'
}
I can successfully use getparam(...) to fetch server_name but I cannot do the same for server_history.
Also, if server was a class as opposed to to a defined type, accessing this variable is straightforward using something like server::serverhistory
Does anyone have any ideas on how to expose these variables? Or am I approaching this completely the wrong way?
Edit: For some higher level context on what I'm trying to do my server type gets instantiated by 3 other classes. A variable in the server type builds out some directory paths based on parameters provided to it by these classes (which naturally, are specific to those classes). There are some other classes that would like to use the directory path variable to place files there.
You ask
I'd like to access attributes that are inside instances of defined types from other classes/instances.
and you go on to clarify that you're after
arbitrary variables.
In fact, ordinary variables in the body of a defined type are not attributes of that type, nor of any instance thereof. They are not part of the accessible persistent state of instances of such types at all.
More generally, Puppet treats defined types just like native types in almost every observable way, but by the same token, it does not provide any features that serve to distinguish defined types as a special case. You are looking for such a feature, and it does not exist.
Since your design idea will not work, you'll need to think of an alternative. You say
my server type gets instantiated by 3 other classes. A variable in the server type builds out some directory paths based on parameters provided to it by these classes (which naturally, are specific to those classes). There are some other classes that would like to use the directory path variable to place files there.
Since the paths you're after are characteristic of specific classes, it makes sense for them to be accessible directly via those classes. It seems odd to me that you would even want to access them indirectly via resources declared by those classes.
I use AvroParquetInputFormat. The usecase requires scanning of multiple input directories and each directory will have files with one schema. Since AvroParquetInputFormat class could not handle multiple input schemas, I created a workaround by statically creating multiple dummy classes like MyAvroParquetInputFormat1, MyAvroParquetInputFormat2 etc where each class just inherits from AvroParquetInputFormat. And for each directory, I set a different MyAvroParquetInputFormat and that worked (please let me know if there is a cleaner way to achieve this).
My current problem is as follows:
Each file has a few hundred columns and based on meta-data I construct a projectionSchema for each directory, to reduce unnecessary disk & network IO. I use the static setRequestedProjection() method on each of my MyAvroParquetInputFormat classes. But, being static, the last call’s projectionSchema is used for reading data from all directories, which is not the required behavior.
Any pointers to workarounds/solutions would is highly appreciated.
Thanks & Regards
MK
Keep in mind that if your avro schemas are compatible (see avro doc for definition of schema compatibility) you can access all the data with a single schema. Extending on this, it is also possible to construct a parquet friendly schema (no unions) that is compatible with all your schemas so you can use just that one.
As for the approach you took, there is no easy way of doing this that I know of. You have to extend MultipleInputs functionality somehow to assign a different schema for each of your input formats. MultipleInputs works by setting two configuration properties in your job configuration:
mapreduce.input.multipleinputs.dir.formats //contains a comma separated list of InputFormat classes
mapreduce.input.multipleinputs.dir.mappers //contains a comma separated list of Mapper classes.
These two lists must be the same length. And this is where it gets tricky. This information is used deep within hadoop code to initialize mappers and input formats, so that's where you should add your own code.
As an alternative, I would suggest that you do the projection using one of the tools already available, such as hive. If there are not too many different schemas, you can write a set of simple hive queries to do the projection for each of the schemas, and after that you can use a single mapper to process the data or whatever the hell you want.
I'm writing an implementation for a mailing service and I'm having trouble with the code that VisualStudio autogenerates from the wsdl file. The API contains several versions of the same objects. The objects are defined in separate xsd files corresponding to a particular version:
Although each xsd file defines a specific namespace, the complex element names are the exact same in all xsd files:
This causes VisualStudio to assign arbitrary names to the classes representing the complex names to retain uniqueness:
If you look at the xsd files, OpenMailingGroup_13B returns an OpenMailingGroupResponse and OpenMailingGroup_15A also returns an OpenMailingGroupResponse, and IMHO that's ok from a definition point of view because they are defined in separate xsd files each having its own separate namespace. However, when VisualStudio generates the proxy classes, it names the return type of OpenMailingGroup_13B as OpenMailingGroupResponse2 and the return type of OpenMailingGroup_15A as OpenMailingGroupResponse4.
This becomes an issue when you update the web service reference and new versions are added and removed (e.g. a new OpenMailingGroup_17X now exists). The problem is that VisualStudio would now use a different naming for the OpenMailingGroupResponse. What was OpenMailingGroupResponse4 for OpenMailingGroup_15A could not be OpenMailingGroupResponse9. And that breaks our code.
We thought of a few possible solutions:
Writing adapter classes - but there are literally hundreds of classes and that would be too painful.
Using var in the variable definition in order not to hardcode the type, but there's lots of nesting involved (e.g. a complex type has another complex type which has another complex type, etc.).
Not update the wsdl...
So, my question is: can I tell VisualStudio to split the generated code into multiple .NET namespaces, each corresponding to its xsd file? Maybe a general question is: is there anything I can do about this?
Thanks in advance,
Tiberiu