VS2015 shows how many references there are to a class.
However if the class is started by WebApplication.Run the references are not shown.
The highlighted code does get executed when the application is run.
Is there any way to get the reference count for the Configure method?
Here are two reasons ;)
The Startup Class is invoked by reflection (it does not implement an interface)
I doubt that code pieces outside of your local source code will influence the reference count. So even if somewhere deep in WebApplication.Run the Configure method is invoked (assuming directly over some magic interface), the reference code will not rise. Make sense, otherwise the counter for string would have overflow ;)
Related
I'm modifying a code written in c++ in order to add several features required by my company. I need to modify as less as possible this code, because it's a public code get from a Git repository, and we want to avoid to deviate from the original source code in case we need to synchronize our code with possible new versions in the future.
In this code, a structure is initialized with a call to std::memset. And I had need to add a shared pointer to this structure.
I notice no issue about that, the code compiles, links and works as expected, and I get even no warnings while the compilation.
But is it safe to achieve that this way? May a std::shared_ptr be correctly initialized if it is part of a structure initialized with std::memset? Or are side effects or hazardous issues which prevent to do that?
Let's say I want to load an FXML document to be used somewhere in my application. As far as I'm aware, there are two ways of doing this:
Call the static FXMLLoader#load(<various resource args>) method.
Initialize an FXMLLoader (with the resource location), and then call load() on that instance.
My question is what exactly "loading" an FXML document does here.
Initially, I assumed the static method would do an entire parse "cycle" on every call, and that creating an instance would allow multiple loads to take advantage of some kind of preprocessed representation, but documentation for the non-static load() method just states;
"Loads an object hierarchy from an FXML document. The location from which the document will be loaded...", which sounds like the document is loaded on every call.
I'm using JavaFX 17.
After spending a fair bit of time with the source, I feel I can give a pretty good overview of how FXML loading functions behind the scenes. That being said, I can't guarantee that there isn't anything I didn't miss. I've thoroughly looked over quite a bit of code I thought to be important, but most isn't all, and I may have simply not noticed something.
This answer should be valid for JavaFX 17.
As a TLDR answering the main concern of my question: As far as I can tell, no information is cached across load() calls, regardless of whether you use the static or non-static versions. That being said, the non-static calls will still give you a slight performance gain, the fastest of which is the load(InputStream inputStream) overload, which (in addition to skipping some argument processing) will prevent the loader from opening a new InputStream on every call.
I've built a call graph (CallGraph Viewer) showing important parts of the FXML loading code in order to make it a bit more digestible.
This is easily the most likely part of my answer to contain inaccuracies. To generate this graph, I simply copied the FXMLLoader code into eclipse and generated connections for parts of the code I deemed important. Unfortunately, the plugin doesn't always correctly parse code containing missing imports, requiring me to write in definitions for a couple of classes, but I left most alone. Additionally, the initial result was incomprehensible and needed a fair bit of manual cleanup, a large portion of which was done simply based on whether I thought something sounded useful or not.
If you are unfamiliar with eclipse's icons, documentation can be found here (make sure to zoom the image, or open it in a new tab, or I doubt you will be able to see much).
Yes, there are three processEndElement() methods with the same signature, they are overridden methods in subclasses of Element.
If you're wondering what I spent all that manual cleanup time on, try not to worry about the individual methods, more the overall structure.
Here's my breakdown of this mess as a step by step recreation of what happens when load() is called:
The application calls one of the public load() methods. This simply calls a matching loadImpl() overload (static if the load() call was static and vice-versa) with the provided arguments. All existing loadImpl() overloads also ask for the class which called them, which the method attempts to provide with a java.lang.StackWalker. No additional processing is done.
After passing the public interface, execution is routed through a hierarchy of loadImpl() calls. Each overload just calls an overload with one more argument than itself, passing on its own arguments and giving null for the missing one (except in the case of a missing charset, which is given a default value).
The more arguments you give to load(), the farther you start in the hierarchy, with non-static versions beginning after the static ones. If you call one of the static overloads, an instance of the FXMLLoader class is created at the final static loadImpl(), which is used to continue onto the non-static calls.
Once reaching the non-static loadImpl() calls, things begin to get interesting. If using the load(void) overload, an InputStream is created based on arguments set when the FXMLLoader instance was initialized, and is given to the next stage in the hierarchy as before. At the final (non-static) loadImpl() (which can be called immediately using the load(InputStream inputStream) overload; this is the fastest method I know of to get from the initial load() call to XML processing), we finally exit the loadImpl() hierarchy, and move to XML processing.
Two things happen here:
a ControllerAccessor instance is given the callingClass argument passed up the loadImpl() hierarchy. I can't exactly explain how this class works, but it contains two Map's; controllerFields and controllerMethods, used in the initialization of controllers.
clearImports() is called, clearing packages (a List) and classes (a Map), both used in further XML processing.
The four variables here (except for maybe the controller ones, I'm a little iffy on them) act as important cache data for the backend XML processing cycle. However, all are cleared between loads (there is no logic controlling their execution, if the load succeeded, the cache data will not have survived), so using an FXMLLoader instance will not improve performance due to data caching (it's still worth using one, however, as the non-static calls skip much of the loadImpl() hierarchy, and you can even reuse the InputStream if using that particular overload).
Next, the XML parser itself is loaded. First, a new instance of a XMLInputFactory is created. This is then used to create a XmlStreamReader from the provided InputStream
Finally, we now begin actually processing the loaded XML.
The main XML processing loop is actually relatively simple to explain;
First, the code enters a while loop, checking the value of xmlStreamReader.hasNext().
During each cycle, a switch statement is entered, routing execution to different process<X>() methods depending on what the XML reader encounters. Those methods process the incoming events, and use an assortment of more "backend" methods to carry out common operations (The 'backend XML processing' section of the call graph is only a small portion of the actual code). These include methods like processImports(), which calls importPackage() or importClass(), in turn populating the packages and classes caches. Those caches are accessed by getType(), a backend method used by many other processing methods.
Additionally, I think that some part of controllers is "assigned" during this stage; processEndElements(), for example, ends up calling getControllerFields() or getControllerMethods(), which access the aforementioned controllerFields and controllerMethods caches, but also sometimes modify them. That being said, the call graph gets a bit too deep for me to easily understand at this point, and those methods are also called later, so I can't be sure.
After XML processing, a controller (controllers? see comment below) is initialized. You can read about controller initialization a bit in James_D's answer here, but I don't have much to say about it, as this is the section I am least confident in understanding.
That being said, it is interesting to note that this code is out of the previous while loop; only one initialization method is called. Either what seems like one call is actually multiple (which is definitely possible; the initialization "method" called is returned by controllerAccessor.getControllerMethods() and "it" is called using the MethodHelper JavaFX class), or only one controller is initialized here (assumedly the controller for the root node) and the others are initialized during parsing. I'd lean towards the first possibility here, but that's based purely on intuition.
Finally (and if you're still reading by now, consider me impressed), we enter cleanup. This stage is super simple;
The ControllerAccessor has its "calling class" variable nulled, and its controllerFields and controllerMethods caches cleared.
The XmlStreamReader instance is nulled.
The root node is returned, and thus the function exits.
Thanks to #jewelsea for links to other answers and for recommending I look at the source.
I have an .ear file with dozens of EJB jar files in it.
Each EJB jar file has dozens of EJBs in it.
Each EJB has #EJB references in it with no other information (no name attribute, etc.).
At the moment everything Just Works: it just so happens that for any given #EJB-annotated injection target there is exactly one concrete EJB that is present in the .ear file to fill the slot.
I need for various reasons to introduce a few more EJB jar files that contain EJBs that could also fill some of these slots.
Hence, I need to tell my Java EE container which EJB to inject into which slot where there are conflicts.
I am familiar with the ejb-jar.xml deployment descriptor mechanism for overriding EJB references but if that is my only recourse I'm looking at changing possibly thousands of these entries.
I noticed in the application.xml schema version 6 that there is support for <ejb-local-ref> elements in there, too, which is in some abstract way what I want. But I cannot figure out how to make use of these elements to do what I want.
In some abstract perfect world, I'd like to somehow say, in one place, "Hey, Java EE container, when you see an #EJB-annotated field like this:
#EJB
SomeType bean;
...please inject the EJB whose beanName is fred into it. Everywhere in this application." How do I do that?
There's no standard way to do it and as far as I know, no common vendor-specific way to do it.
This is something i tried to get in in EJB 3.1 for EJB and JPA refs: if an injection point works using the default rules because there's only one SomeType bean, but then some day a second SomeType bean is added... to be blunt, you're hosed :) This problem also exists for #PersistenceContext and #PersistenceUnit refs. The idea was/is to have some "this is the default impl of SomeType option in the standard deployment descriptors and bail people out of these situations.
We should still get this into the specification. If this is your problem, I'll repost that proposal and if you can please follow up with information on how much of a nightmare this is for you, I can almost guarantee we'll get this fixed for EJB.next.
Get your canonical xml
For now, one possible approach is to temporarily deploy this ear in TomEE using the flag openejb.descriptors.output=true. TomEE/OpenEJB will actually give you all the effective deployment descriptors for your application. Could save you several hours or days if your application is as large as you state. Internally we 1) read in the deployment descriptors, 2) use the annotations to "fill out" the deployment descriptors. The result is we have a tree which is the canonical set of "metadata" for each EJB module. With the openejb.descriptors.output=true flag set, we will write each of these ejb-jar.xml files to disk and log the location.
Once you have your ejb-jar.xml files in hand, you can modify at will and go back to GlassFish and perhaps have better luck.
Overriding: Control your reference counts
In terms of how to actually manage this in Java EE, you have to understand how to be successful in overriding references. There's a critical bit of info one needs to know in how annotation references translate to xml. The goal is to have 1 reference and not N.
When your reference is unnamed like so:
package org.some.awesome.code;
public class Foo {
#EJB
SomeType orange;
... there's a fixed rule that the default name of this must be org.some.awesome.code.Foo/orange. The class name and package become part of the name so as to give you the most fine grained control in overriding. The following xml will override this reference:
<ejb-local-ref>
<ejb-ref-name>org.some.awesome.code.Foo/orange</ejb-ref-name>
<local>org.some.awesome.code.SomeType</local>
<ejb-link>Fred</ejb-link>
</ejb-local-ref>
This reference will now link to the EJB of type SomeType with the beanName 'Fred'.
The disadvantage of this is that if you have 100 references like this and you want to change them all, you will need 100 declarations in xml to do so.
There's no way out of this problem that doesn't involve changing your code -- this is where my "use this as the default" proposal has value, it would allow one xml change to handle all 100 cases with no code change. It's as simple as being able to say "when I'm not specific in my code, I really mean use X" via the deployment descriptor.
Perhaps by making it legal to declare overrides in xml using just the type, like so:
<ejb-local-ref>
<local>org.some.awesome.code.SomeType</local>
<ejb-link>Fred</ejb-link>
</ejb-local-ref>
As mentioned, this is currently not legal.
Changing your code
There are a few code change approaches available, but one of them is to give each #EJB ref the same name. Then you will end up with just 1 reference rather than N.
package org.some.awesome.code;
public class Foo {
#EJB(name "purple")
SomeType orange;
Here the name of the reference is explicitly given so overriding it in xml can be done more simply as follows:
<ejb-local-ref>
<ejb-ref-name>purple</ejb-ref-name>
<local>org.some.awesome.code.SomeType</local>
<ejb-link>Fred</ejb-link>
</ejb-local-ref>
If there are 100 #EJB(name="purple") references, all of them would be overridden by the above declaration.
Conclusion
Short answer, there's currently no easy way out. You're looking at either extensive xml or extensive code change.
Long term, we can hopefully improve this part of the specification so people aren't punished when they grow out of the default matching rules.
I am currently solving the same problem. I am investigating possibility of overriding the JNDI context so it provides other instance than the standard ones. You just have to set the system property java.naming.factory.initial (e.g. in jndi.properties) to your implementation and put the implementation on the root classpath. Then in the factory you create your own version of context with overridden lookup method. Sounds simple, but I am figting with this for days.
iam begineer in ejb's.I have one doubt in ejb 2.0,In session beans,i will create() with out args in EJBhome.But i didn't define any methods i.e., ejbcreate and ejbremove in the bean.So,Can i compile or run this code without those method in the bean?.
You can compile it but cannot run it. You must have a matching ejbCreate() method in your bean class.
If you are very new to EJB I recommend testing your code with OpenEJB (here's a getting started video). Not because I work on the project (which I do), but because we aggressively check code for mistakes and will print clear errors as to what you might have done wrong.
The output can come in 3 levels of verbosity. On the most verbose level, the output is more email response oriented and error messages include information like "put code like this -code-sample- in your bean." The code samples even try to use your method names and parameter names where possible.
As well it is compiler style. Meaning if you made the same mistake in 10 places, you will see all 10 in the first run and then have the opportunity to fix them all at once. Rather than the traditional style of fix 1 issue, compile, test, get same error elsewhere in code, repeat N times.
And of course you can still deploy into another EJB container. Sounds like you are stuck using a pretty old one if you have to use EJB 2.0.
Here's a list of some of the mistakes that are checked
Ok, so I know that global variables are considered bad, and the singleton pattern is overused. And I have read in many places that a class should do only one task and contain only those variables that allow it to accomplish that one task. However, while working on my latest project, I actually thought about these rules before writing any code and have noticed that I tend to break them at the very beginning of the program.
I'm currently working on an MFC dialog based application, but this question could be applied to any UI driven application. I have separate classes that handle state machines, file reading/writing, and hardware interfacing. All of these objects will need some type of UI control or property display/editing. In the MFC dialog applications, the dialog is the program, so it must exist until the program is closed. I've usually just put the objects in the main dialog class for the application and had the dialog class serve double duty; as both the main UI and the home for all other objects in the application. In other applications, I've created these objects globally and referenced them from wherever they were needed. Neither of these ways seem correct. The first option breaks the one class, one task rule, and the second relies on globals and also creates hidden dependencies. I could institute some type of dependency injection, but where would all these variables that I would inject reside?
I'm just wondering what others do to organize their programs without breaking the rules?
I find that storing singletons as public data attributes of the main dialog class of an MFC dialog application works OK for a quick and dirty program. However, as the program becomes larger and more complex, things begin to get untidy.
The point where storing singletons in the dialog class needs to be refactored is probably when you start passing pointers to the dialog around, so that other classes can access the singletons it contains.
The singletons can be moved into the global namespace. This is still a bit untidy, especially when there are a large number of them. Since you have to write a separate extern for each one in a header file then define each one somewhere, you soon end up with something that looks a lot like an old fashioned C program.
A neat thing to do is to make use of the singleton that the framework has already defined for you.- the application object which is always called theApp, a specialization of CWinApp. If you place your singletons as public data members of this, then any code can get easily get access to them .
Suppose that you called your application “solver”. The dialog application creation wizard will create a class CsolverApp. Now suppose you have a singleton called ‘theData’ an instance of the class ‘cData’.
Place your singleton in the theApp
class CsolverApp : public CWinApp
{
public:
cData theData;
…
Now to access this from anywhere in your code
#include “solver.h”
theApp.theData.somepublicmethod();
It does make sense to look at this from the MVC (Model - View - Controller) viewpoint. (That the naming of MFC is an homage to MVC is another sick joke on Microsoft's part; it is hard and unintuitive (but by no means impossible) to manage the types of abstractions that are necessary in "true" MVC within MFC.)
Specifically, it sounds like you've thought out the basis for MVC design; you have the classes that do the underlying business logic work (the Model), and you know they should be separated from the UI components (the View). The issue that comes in now is the third part of the MVC trinity; the Controller.
MFC makes this stuff tough by apparently purposefully obfuscating the MVC process, by making you start with a Dialog. In your instance, the Dialog that MFC is starting you off with should be the Controller, and NOT the View. What your Dialog (Controller) is doing for you is managing your UI components (View) and allowing them to interact with your "work" classes (Model). What makes this tough again is that your UI components, to be visible, most likely need to be attached to your Dialog to be visible.
To get this sort of thing right, you really have to basically implement your Controller as a high-level object that gets instantiated from your Dialog; your Dialog is where the initial control flow comes in, your Controller gets control flow, and from there, it should treat the Dialog as just another UI component (albeit one with special status).
This allows you to have the proper level of encapsulation; your Controller invokes your business logic (Model) classes, which can communicate with each other or with the Controller as appropriate; they are segregated from the View by the Controller, instead of being embedded in the UI components and (likely) taking the "easy way" of over-privileged access to UI elements ("Hmm, I need this object to get some input from the user; I could refactor, but it'll be so much easier to just throw a dialog box up, since I have the top-level window handle...").
Once your Controller object is the home to all of the business logic objects, things become easier; you can use the Controller to provide cross-object access for any objects that need other objects. Think about which classes need to be Singletons, and use them sparingly. Resources that need contention management (such as hardware resources) are great examples of "natural singletons"; things which lend themselves to a singleton approach. You may also choose to make your Controller a singleton; depending on the requirements for access to it. Specifically, in your Dependency Injection scenario, the Controller is where you'd instantiate the objects and manage the dependencies.
This is the basic MVC approach; but, like I say, MFC makes it unusually hard and unintuitive, because of the fundamental design of MFC. I learned MUCH more about MVC AFTER an initial VERY negative impression about it due to MFC; if you can, I recommend looking into what MVC implementations look like in other languages.
Good luck!
If I am understanding you correctly, it sounds like the lifetime of your dialog objects is too long. Rather than maintaining the dialogs for the duration of your program, you should consider creating and destroying them as they are needed.
Also, global variables (or singletons) are OK so long as the thing that the variable represents is truly a global thing that persists for the lifetime of the program, rather than just a place-holder for an object of lesser duration. Using globals for the wrong things for simplicity sake will come back to bite you eventually, even if the globals are stored on the main dialog.