Using Discoverer as part of a larger application

The project I am working on is looking to use Discoverer as an End User Query tool within a large application. What we would like to be able to do is to utilize a single logon for the user. This would mean that we would somehow have to be able to programmatically bypass the Discoverer signin screen. We already know the user id/password and do not want to have the user to sign in a second time. Is this possible?

Hi,
In order to use discoverer from your application you need t use Discoverer COM'S objects that are registered in the Windows registry.
Amit

Similar Messages

  • How to use Source Code Control for Large Application?

    Hi, All!
    I would like to collect knowledge about "best practice" examples for using Source Code Control and project organization for relative large application (let's say approx 1000 SubVIs).
    Tools used:
    LabVIEW 8.0
    CVS Server
    PushOK CVS Proxy Client
    WinCVS
    With LabVIEW 8 we can organize large project pretty well. This described in article Managing Large Applications with the LabVIEW Project.
    I have read this article too: Using Source Control Software with LabVIEW In this Article Source Safe used, but with PushOK all looks nearby the same and works (some tricks for compare function are required).
    Example. Two developers working together on same project. Internally project is modular, so one developer will work with module "Analysis", and another one with "Configuration" without interferences. These modules placed into Subfolders as shown in example above.
    Scenario 1:
    Developer A started with modification of module "Analysis". Some files checked out. He would like to add some SubVIs here. So, he must also perform check out for the project file (*.lvproj), otherwise he cannot add anything into project structure.
    Developer B at the same time would like to add some new functions into module "Configuration". He also needed to check out project file, but this file already checked out by Developer A (and locked). So, he must wait until lvproj file will be checked in. Another way is mark *.lvproj files as text files in PushOK, but then one of developers will get conflict message by checking in and then merging will be necessary. This situation will coming very often, because in most cases *.lvproj file will be checked out all the time.
    Question: Which practice is better for such situation? Is Libraries better than folder for large project?
    Scenario 2:
    Developer C joined to the team. First, he must get complete project code for starting (or may be at least code of one Library, which assigned to him).
    Question: How it can be done within LabVIEW IDE? Or WinCVS (or other SCC UI) should be used for initial checkout?
    Scenario 3:
    Developer D is responcible for Build. Developers A,B,C have added lot of files into modules "Analysis", Configuration" and "FileIO". For building he need to get complete code. If our project splitted into folders, he should get latest *.lvproj first, then newly added SubVIs will appear in Project Explorer, then he should expand tree, select all SubVIs and get latest versions for all. If Project organized in Libraries, he must do the same for each library, isn't?.
    Question: Is this "normal way", or WinCVS should be used for this way? In WinCVS its possible with two mouseclicks, but I prefer to get all code from CVS within LabVIEW IDE recursively...
    That was a long post... So, if you already working with LabVIEW 8 with SCC used for large project, please post your knowledge here about project structure (Folders or Libraries) and best practices, its may be helpful and useful for all of us. Any examples/use cases/links etc are appreciated.
    Thank you,
    Andrey

    Regarding your scenarios:
    1. Using your example, let's say both developers checked out version 3
    of the project file. Assuming that there are only files under the
    directories in the example project, when Developer A checks in his
    version of the project, there will be new files in one section of the
    project separate from where Developer B is working. Developer B,
    notices that there is now a version 4 of the project. He needs to
    resolve the changes so will need to merge his changes to the latest
    version of project file. Since the project file is a text file, that is
    easy to do. Where an issue arrises is that after Developer B checks in
    his merged changes, there is a revision 5. When Developer A and B go to
    make another change, they get the latest version which will have the
    merged changes to the project file but not the referenced files from
    both Developer A and B. So when A opens version 5, he sees that he is
    missing the files that B checked in and visa versa. Here is where the
    developers will needs to manually use the source control client and,
    external to LabVIEW, get those new files.
    Where libraries help with the above scenario is that the library is a
    separate file from the project so changes made to it outside of the
    project do not require the project to be modified. So this time, the
    developers are using a single project again which time time references
    two libraries. The developers check out the libraries, make changes to
    the libraries, and then check those changes in. So when each developer
    opens the project file, since it references the project file, the
    changes to the library will be reflected. There is still the issue of
    the new files not automatically coming down when the latest version of
    the library is obtained. Again, the developers will needs to manually
    use the source control client and, external to LabVIEW, get those new
    files. In general, you should take advantage of the the modularity that
    libraries provide.
    2. As noted in the above scenario, there is no intrinsic mechanism to
    get all files referenced by a LabVIEW project. Files that are missing
    will be noted. The developer will then have to use the source control
    provider's IDE to get the initial contents of the project  (or library).
    3. See above scenarios.
    George M
    National Instruments

  • After updating to mavericks I have to constantly enter my apple ID for mail, iBooks, iTunes and many other applications that used to be part of my keychain. How can I get my log-in to work again?

    After updating to mavericks I have to constantly enter my apple ID for mail, iBooks, iTunes and many other applications that used to be part of my keychain. How can I get my apple ID log-in to work again?

    Several times I've re-entered my passwords under Preferences/Internet Accounts/iCloud and it won't save since I've installed Mavericks.  Also, the iCloud icon in the left column in Preferences/Internet Accounts/iCloud is greyed out but allows me to click on it to set-up.  When I click on iCloud the password is filled out but the "Enable this account" check-box is not checked.  I check it, and all seems correct.  The icon is no longer grey, the password is correct, the "activate this account" check-box is checked.  Then, when I launch mail, notes etc. I'm still prompted to re-enter my apple ID.  The log-in loop continues.  For years my keychain has worked perfectly.  What has changed in Mavericks?

  • Deploying large applications and common used classes

    I've got an application containing EntityBeans, statefull/stateless
    SessionBeans, and a Webapplication. Every component is packed in a jar File
    and all together in an EAR-File as an application.
    Those EJBs share some common classes, for example:
    EjbA in A.jar and EjbB in B.jar share a Helperclass C.
    Where do I put this class C? I try to avoid to put this class C in the
    Classpath of the application server. And when I put C in both jar-Files I
    got a ClassNotFoundException in one of the EJBs. I'm using WLS 6.0.
    Any ideas? Thanx in advance.

    FYI, this is fixed in 6.1
    Torsten Friebe wrote:
    Hi Daniel,
    thanks, this article answers my question. But does WLS 6.0 or 6.1 allready
    support J2EE Packaging as described in J2EE 1.3 Spec (PFD3) Chapter 8?
    Cheers
    Torsten
    "Daniel Hoppe" <[email protected]> schrieb im Newsbeitrag
    news:[email protected]..
    Hi Torsten,
    there is no really good solution so far. Check out this link, it
    elaborates this topic in detail.
    http://www.onjava.com/pub/a/onjava/2001/06/26/ejb.html
    Cheers,
    Daniel
    -----Ursprüngliche Nachricht-----
    Von: Torsten Friebe [mailto:[email protected]]
    Bereitgestellt: Freitag, 29. Juni 2001 11:59
    Bereitgestellt in: environment
    Unterhaltung: deploying large applications and common used classes
    Betreff: deploying large applications and common used classes
    I've got an application containing EntityBeans, statefull/stateless
    SessionBeans, and a Webapplication. Every component is packed
    in a jar File
    and all together in an EAR-File as an application.
    Those EJBs share some common classes, for example:
    EjbA in A.jar and EjbB in B.jar share a Helperclass C.
    Where do I put this class C? I try to avoid to put this class C in the
    Classpath of the application server. And when I put C in both
    jar-Files I
    got a ClassNotFoundException in one of the EJBs. I'm using WLS 6.0.
    Any ideas? Thanx in advance.

  • Large Application - Should I be using modules?

    I have built an Estate Agency application in Flex 4.6 which is solely used internally.
    Each process within the application, such as editing property information, is handled within a component and some components have sub-components which are loaded via a ViewStack, such as the customer account component which has sub-components like "address information", "summary", etc.
    The problem is when a large component is loaded for the first time which has multiple sub-components, such as the customer account component, data is fetched from the server application (which takes 200ms) and populated into the various TextInput/DataGrid/DropDownList components within the customer account component and its sub-components. This results in the entire application hanging until the components have been populated.
    Is there a way to prevent this from happening, such as being able to load the component and its sub-components in the background, allowing the user to continue using the application in the foreground?
    Would it be more beneficial to use modules instead of components so the code is loaded from a separate SWF?
    Any help and advice would be greatly appreciated. Thanks in advance.

    IMO, If your application is large, modules will likely help in ease of development, load time, and memory management.
    As far as initializing a lot of components and stuffing them with data, I don't think it will matter too much if the components are in a module or not.  You are correct that you want to try to do it in the "background" although there is no official background processing in Flash/Flex.
    IMO, it comes down to whether you really can do all of that work of initializing "all" of the components fast enough.  If you can guess you're going to need those components then you can get a head start, but will you know soon enough to finish before the user starts complaining about waiting?  If you think you can, then one technique folks use is to only initialize a few components at a time.  Use states or pure AS to add and initialize "some" of the components and when they are initialized, do a few more.
    Also consider whether all of these components fit on the screen or not.  If there are components that are not immediately on screen consider initializing them later.
    Another thing worth doing is using the profiler.  Several times I've seen folks go through extra validation passes in the LayoutManager than can often be avoided and save bit on initialization time.
    A final technique is to give up and choose to distract the user instead.  The simplest form of that is giving them something to read while everything else is going on behind the scenes.
    Good luck,
    -Alex

  • Large applications - Labview and other programming languages

    Hello Labview Users,
    as the forum saw this very interesting thread about large applications programmed in Labview
    (see: http://sine.ni.com/niforum/niforum?requireLogin=False&forumDU=http://forums.ni.com/ni/board/message?... ) I would like to ask the community about their experiences with Labview applications in combination with other programming languages.
    In advance: I have several years of experience in programming Labview applications starting from quick-and-dirty solutions which had to run within few hours and complex test solutions. I saw Labview growing and becoming better with the released versions and lot of things I missed in former times got implemented in the meantime. Actually I have to develop a complexe ATE solution with numerous equipment to control and numerous data to be captured and archived. Despite the Verison 8 I still feel still some drawbacks of the LV concept which let me hestitate to setup the solution completly in Labview:
    1) It is alway hard to re-use code of complex applications since it is not possible to do some kind of global search an replace of functions
    variables etc. It nearly impossible to re-use approved code structures (e.g a state machine) if the "inner part" is changing more the a little bit.
    2) If the application requires a certain flexibility (e.g. exchangeable test equipment of varying vendors) this is hard to implement since you have to define a lot of parameters through your hierarchy if you dont want use global variables which slow down your application and hide
    the code functionality.
    3) Despite modern PCs the look and feel of LV applications appears somewhat slow compared to other applications. For complex user interfaces the polling methode generates a lot of complex code. (I dont have expierence with the event-structure).
    Now my questions:
    Do you have experience of implemention of complex solutions dividingthe code modules using Labview and other languages? Which other
    languages did you use? Why did you use these languages (speed, flexibility of text based code, available library functions)? Did you found out this to improve your development time and code maintainibility?
    (I concider a solution where I do the single tests with Labview-VIs but delegate all the test sequencing and data collection stuff written in PERL which allows really very compact code)
    I'm curious what your experiences are.
    rainercats

    Given that you're asking these questions in a forum for LabVIEW users the opinions given are going to be somewhat slanted towards the general like of LabVIEW. I've been working with LabVIEW for a long time, ever since 2.something on a Mac. I've written numerous large-scale applications as well as "mundane" instrument drivers. As you've noted you're experienced with LabVIEW, so you know some of its strengths and weaknesses.
    To address your specific questions:
    (1) Yes, that has always been a limitation in LabVIEW, but I don't believe it is an overriding one to choose C over LabVIEW. Putnam provided one workaround for the search and replace of VIs. Once you've programmed in LabVIEW long enough you get used to doing it this way. Is it clumsy? Yes. As for the re-use of code structures, that's not entirely true. You can create a "template" VI (a regular VI, not a .vit) that contains the code you want to re-use and place in your palette with the "Merge VI" option set. That way you can select it from your functions palette, plop it down on your diagram, and you get the "template" VI's diagram placed right into your new VI.
    (2) This is not something that is specific to LabVIEW, as this exists with any programming language. It's not the language that limits you here, it's how you've designed your code. In a language like C++ you would go with classes. You can do the same thing in LabVIEW. IVI is another option (though not preferred by me).
    (3) As Putnam mentioned, you should be using the event structure.
    Other thoughts:
    The biggest strength I see with LabVIEW is that each VI is a miniature program, which allows development and debugging of functions a snap. With a language like C you have to write another program to call that function in order to debug it. The biggest weakness? I would say user interface. Yes, even with the event structure. Don't get me wrong, the event structure has vastly improved the way user interfaces and event handling in general are done with LabVIEW, but it simply doesn't hold muster to a program written in C or VB. ActiveX anyone? LabVIEW still doesn't do ActiveX properly in terms of actually getting the controls to work. Programming ActiveX controls is just plain aggravating what with all the property nodes taking up so much diagram space.
    It certainly makes sense to use the best tools available to you to get the job done. In my recent projects I had to write software to run automated tests on some products my company made. The test modules were written in LabVIEW. The tests executive was a proprietary engine driven by a SQL Server database. I had to write a "wrapper" DLL that interfaced between the LabVIEW code and the executive since the executive hadn't been designed to call LabVIEW DLLs directly. This allowed us to use LabVIEW as the preferred language for developing the test modules and let the guys who were fiddling with the test executive do their bit. Of course, TestStand's premise is basically that.

  • So why to use Discoverer ?

    Dear all,
    after working as a developer since 1986 with Oracle RDBMS Rev.4 and all those Application Tools (starting with Forms 2.0, raf(rapid application facility) or whatever it was called) I wonder should I talk my customers into using Discoverer Version WHAT.
    Now :
         I'm ready to go the 10g lane.
         but, what about connecting to 8.1.7
         but, look at the staus of this forum : just questions, hardly answers
         does all this web hype work right now ?
         do you have to be a super java/xml/html engineer ?, I'm just a elementary particle physicist, making his money with Oracle rdbms and Tools since almost 20 years.
         any 10-version experiences available ?
         any 9-version solid experiences ?
         I'm ready to jump, any water in the pool ?                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

    Rainer,
    Hello to a fellow old timer. Started in '88 with Oracle Add-in for Lotus 1-2-3. Then joined Oracle to support RDBMS 5.1 and SQLForms/Report/Menu and other products.
    Now a Product Manager for Discoverer so I have an obvious bias so take it as it is.
    Q: I wonder should I talk my customers into using Discoverer Version WHAT.
    A: Yes please do and make it Discoverer 9.0.4 included in Oracle Application Server 10g (9.0.4)
    Q: but, what about connecting to 8.1.7
    A: no problem -- yes Discoverer will run against DB 8.1.7
    When running against higher versions like 9i and 10g Disco
    will take advantage of enhanced functionality like Enhanced Data Aggregation and incremental refresh of Materialized Views.
    Q: but, look at the staus of this forum : just questions, hardly answers
    A: Well I can give you 7 answers right now. Just trying to keep up with the high demand and limited staff.
    Q: does all this web hype work right now ?
    A: Absolutely. It's pretty cool actually. We have a builder/analysis tool that downloads as a Java applet (Discoverer Plus); a Viewer tool (pure HTML from a browser) that allows you to run worksheets and analyze/drill/pivot etc.; and integration with Oracle Portal so you can include Discoverer content in a Portal Page.
    Q: do you have to be a super java/xml/html engineer ?,
    A: You don't need to do any coding to use Discoverer.
    The most challenging part will likely be designing the
    Metadata (Business Areas in the Discoverer End User Layer) to enable your end users access to their data. If you want to customize Viewer you can modify an XML file if you really want to code -- but it is not required. Should be a piece of cake for a particle physicist!
    Q: any 10-version experiences available ?
    Q: any 9-version solid experiences ?
    A: I assume you are referring to Application Server versions. We have successful customers on 9.0.2 and 10g (9.0.4) but we obviously are encouraging customers to get up to the 9.0.4 release. It has the most functionality and is very stable.
    Q: I'm ready to jump, any water in the pool?
    A: Come on in. The water's fine.
    Discoverer Product Management

  • Large application: how to structure?

    Hello JHS team,
    At my current customer, there is a very large Forms application (Designer generated, +100 fmb's). On the long run, the goal is to get this application migrated to ADF using JHS. With or without the forms to ADF conversion utility.
    My question now is how to structure the ADF/JHS version. The Forms application has a menu on top of the screen, with a hierarchical structure. Each menu item links to a specific .fmb in the application, and some fmb's are also linked to eachother.
    My initial thought was to make one ADF application (Model-ViewController), and for each fmb to create an equivalent Application Module. Or in JHS terms: each fmb represents a service. This way the (dynamic/static) menu feature of JHS could be used.
    Needless to say, this one application would become too large to maintain. And the largest disadvantage of this approach: it would not be possible to deploy an individual service, because the whole application would just be one .ear file after deployment. On the contrary, in Forms, an .fmb can easily be regenerated from Designer and deployed to the server. Without affecting the rest of the application.
    Another approach would be to make a new ADF application, with separate Model and ViewController project, for each fmb. But how to reach a menu structure then? Linking to a deployed ADF application requires quite an exotic URL, which you don't want hardcoded in your menu...
    How would this be solved in the cleanest way? Keeping in mind that an individual part of the application (ie the equivalent of one fmb) should be redeployable on its own, that there should be a menu to navigate to the different applications and that linking different application (incl passing parameters?) could be necessairy? Am I missing something obvious, or is this just very hard?
    We are using the latest JDev 11g version with (one of) the latest JHS build(s).
    Thanks for your input!
    Chris

    Chris,
    Please use the internal mailing list.
    The forum is intended for customers/partners.
    Btw, The ADF Methodology group has quite a few interesting threads related to structuring large ADF apps.
    Steven Davelaar,
    Jheadstart Team.

  • Troubleshootings while building large application

    Hello,
    I am currently trying to build a large application :
    - ~6000 vis,
    - ~300 or 400 classes,
    I am quite proud of the code, because there is only 1 vi not packaged in a lib or 1 class, it's the Main_App.vi that launches the application.
    Architecture is based on Model View Presenter design pattern.
    When I try to build the application Labview just process for hours and don't even moves.
    Last night, I let him go for 10 hours and it and just processed 1 class.
    I tried using Libp to package part of the code but with no success, a lot of linkage troubles occurs when I try to use them. And management of redefinition seems to broke Vis.
    As any body encounters that king of situation and even solved it.
    Any Ideas...
    The software have to be delivered within a week and it makes me sick not to be able to make usable to work we have done for months....
    Thanx for answers.
    Pierre
    Coss-post : http://lavag.org/topic/15004-troubleshootings-while-building-large-application/

    Hi,
    Please have a look at this thread,
    Re: Error in CompatibilityMode
    Regards,
    Saravanan K

  • Organize JDev for large applications

    Hello JDev team,
    In order to properly manage very large applications and different versions of the same application (like maintenance and development) in the same environment, there are various settings that would find their more appropriate place at the level of the workspace.
    I already saw some other threads discussing similar topics, I would only like to put them together and try to get some schedules :-)
    1. One problem is that there are no nested workspaces, and you don't have good "visibility" outside your own workspace (one example, you cannot create a BC Client Data Model unless the BC project is in the same workspace).
    Nested workspaces would be great for properly organizing a large application. If you implement this, please don't forget the visibility "details".
    2. A quite different problem is related to the definition of libraries. Once you have to manage in parallel, in the same environment, different versions of the same application, things become hard to manage.
    Most of the projects should have their associated library defined, as there are relations between projects. But a library entry is absolute, so it stands for one version. When you have to switch to another version (which is also under SCM), there are different physical paths on the disk, so different values for the libraries. And you have to change (one by one or directly in libraries.xml) their definitions.
    This would be solved naturally if the libraries were defined for a workspace. And would also provide the possibility to have relative paths rather than absolute ones, which is easier to manage.
    3. Base classes. It is nice to have this in the global Preferences, but, as somebody else noticed before me, it might be necessary sometimes to have different base classes for different applications, all in the same development environment. This comes similar to having base classes defined (also) at the level of the workspace.
    4. Debugger/Breakpoints/Default Action. This is another kind of preference I would like to have at the level of the workspace, or even for each project. Especially because of the "Group of Breakpoints" section.
    5. Deployment. Here, a new option "Relative to Workspace Directory" would do. Or, allow the definition of the default deployment directory for each workspace.
    6. Web Browser/Proxy. Well, here my problem might be more specific. We access internet resources via a proxy, so when it comes to accessing Oracle resources (like Check for Updates...) from JDeveloper, the proxy setting is useful, even required.
    But, in our intranet development, we do not use a proxy (not the same, anyway). So, for normal development purposes, there should be no proxy.
    In this case, what I would like would be to have the global setting in the IDE preferences used for global resources, while the setting in the workspace (if any) will be used for the application-specific resources (e.g. servlet URL).
    I am quite sure I did not cover all the possible enhancement topics, but I hope things will be checked carefully.
    Apart from adding valuable features for developers, the approach of moving certain preferences from the IDE to a "work component" (workspace, project) would also help team-work.
    Once one team member will set some preference(s) for a workspace (and put it under SCM), this setting(s) will be automatically available to all other team members.
    Could you please comment my issues and tell me which of them (with the solutions that you foresee) could integrate 9.0.4?
    Thank you,
    Adrian

    Hi Adrian,
    Thanks for the detailed feedback.
    I agree with you that there are significant issues when using project files at the moment in a team environment, particularly when an SCM system is involved. And since a recent survey indicated that the majority of JDeveloper users use some kind of SCM system, it's particularly important that we address this in future releases.
    At the moment, I'm putting together some suggestions for future changes in this area from the point of view of the feature team who develop SCM support in JDeveloper. Your ideas are useful input into this process. Sadly, it's unlikely that any major changes to the way project files are stored will make it into 9.0.4, since 9.0.4 has already gone into "bugfix only" mode, and the focus of the 9.0.4 release has been on performance improvements and stability. However, we are looking at this issue for a future release (possibly 9.0.5, although these discussions are at a very early stage).
    I've included comments on some of your specific points below.
    1. Nested workspaces
    There was some discussion about whether we should use nested projects a long time ago (i.e. get rid of the concept of a workspace altogether, and just allow projects to contain, and presumably inherit properties from, other projects). This is currently being tracked as ER 2048949. It requires a substantial change to the architecture of JDeveloper and could have a massive effect on components across the IDE. I believe that a lot of the issues with project files can be solved in other ways without going to the extreme of using nested projects / workspaces.
    2. Library Definitions
    Project-scope libraries should hopefully make this a whole lot easier in 9.0.3. I also like the idea of defining libraries at the workspace level so that they can be shared between projects; alternatively, using a "library definition" file as a separate, version-controllable resource that can be referred to by a project. I've filed ER 2689043 to track this.
    3. Base Classes
    This is a BC4J thing, and a bit outside my area of knowledge :) I'll pass your suggestions along.
    4. Debugger Preferences
    I'm not sure what you mean by "group of breakpoints section"
    5. Deployment
    Filed ER 2689052
    6. Web Browser/Proxy
    You might be able to make use of the "Exceptions" field in the proxy settings to help with this. Within Oracle, we have exactly the same issue, but normally use an exception list that looks something like this: "localhost|127.0.0.1|*.oracle.com|*.oraclecorp.com|*.oracleads.com"
    One of the areas I'm interested in seeing improved is the concept of "configurations" that we currently have in project files. For example, it would be nice to define a workspace-scope configuration that's inherited by projects. Also nice would be the ability to allow read-only configurations (that are source controlled as part of the checked in project definition) and user/view-specific configurations (which would not be version controlled). The user/view specific configurations could inherit preferences from the read-only configurations, and the user could override things in a way that wouldn't affect other users (e.g. in the "Paths" preferences, change the output directory to one on their own local machine) without having to check out the project file from source control.
    Thanks,
    Brian
    JDev Team

  • Bc4j; large application approach

    To follow up on an offline conversation.
    If one were to build a Very Large Application or Application Suite using JDev, does the following make sense as an approach?
    1. Set up a project with all your Domains, entity objects and View objects to be used across all other projects. This is maintained by someone (like a dba) who puts validations, defaults, rules, and the like here. Periodically this could be generated into a library for use by other projects. ( Hmmm... I don't know how to do that yet... )
    2. Set up projects for each of the applications. The entity/view objects and such DO NOT appear directly in this project ( and you might not want all the programmers to have updateable access to 'em anyway... it needs to go through some sort of command/control structure ). They use the library to add their own special view objects and such... and build the application.
    Will that work? Is that the way it should be put together?

    Business Components can be packaged up for deployment and reuse like any java classes.
    You can easily create a JAR file for all of the common entity objects, associations, domains, and base view objects of use to multiple applications. You can use the standard JDeveloper deployment wizard for this, and indicate that you want to create a "Simple Archive File". What will get JAR'ed up will be all of the XML and *.class files that comprise your components.
    Then, any other BC4J project can include this "application core" JAR file as a library and then import all of the components (READ ONLY). All of the core components are available for reuse, but the imported components cannot be modified in the importing project.
    See the help topic:
    Developing Business Components[b]
    --[b]Working with Business Components Projects, ...
    ----Ways to Import Existing Business Components
    for more details.
    Each new application you build will likely need some application-specific view objects, so I wouldn't work under the assumption that all view objects need to live under the "core" project.

  • File structure in large applications

    Hello,
    I have a fairly large application, totaling around ~150,000 lines of code.
    Unfortunately, when I first began building this application, my understanding of file structure and various architectural patterns was quite limited, and the code could easily be labeled as "spaghetti code."
    Since then, I have begun migrating everything over into an MVC structure, but was not entirely sure how to proceed.
    I have one primary file, let's say Application.as that is essentially the main actionscript class, and I am using 'include "com/controller/hello.as"' instead of importing classes because I did not want to clutter up my code by using classes all over the place and having to instantiate them.
    Would creating classes instead of having flat actionscript files be a better way to proceed?
    How do you structure your large applications?
    Are there any resources out there, articles, books, etc., that discuss enterprise level architectural patterns in Flex?
    Thanks!

    Flex is an Object Oriented environment and so NOT using classes and objects will generally lead to the architectural anti-pattern (read Bad) sometimes refered to as the Big Ball Of Mud (aka spaghetti code).
    Just using classes and objects isn't always enough though. If a class is larger than 500 lines of code, it is very probably too big and doing too many things - try and split it up into smaller classes that each do exactly one thing and do it well. If a function is longer than one screen on your display, it is too big and should be broken down into smaller functions.
    One good indicator as to whether or not you have a good class is to use a unit testing framework (http://flexunit.org/) and write tests for the class. If it's hard to test it then it's probably still too complicated.
    How the classes are organized into packages is a less interesting, though if a package has more than 30 classes then there's a good chance that it's too big and you should try and divide it up.

  • Migration of large application from JDK1.4 to 1.6

    Hi,
    I want to migrate some large application code base's from jdk1.4 to jdk1.6. Need some help regarding this. Please let me know the following as mentioned below :
    1. Is there any tool/s available that can be used for this migration (Because manually it is very difficult for a application with almost 15,000 java files and 15 * 10^6 KLOC within a limited time frame).
    2. Steps that should be followed in such cases.
    3, If any tool is not available for such activity what are the salient points that are needed to be considered while migrating.
    Thanks in advance
    AnjanN

    I want to migrate some large application code base's from jdk1.4 to jdk1.6. Need some help regarding this. Please let me know the following as mentioned below :
    1. Is there any tool/s available that can be used for this migration (Because manually it is very difficult for a application with almost 15,000 java files and 15 * 10^6 KLOC within a limited time frame).
    2. Steps that should be followed in such cases.
    3, If any tool is not available for such activity what are the salient points that are needed to be considered while migrating.
    What is it that you think needs to be 'migrated'?
    Most applications will run just fine using 1.6 - it is compatible with 1.4 already.
    You need to conduct your own tests using 1.6 to see if there are any problems/issues with your app.

  • Dynamically loading a class that is part of a larger loaded package

    I am dynamically loading a class that is part of a large package, much of which is loaded at startup. The code directly references protected variables in the parts of the package that is loaded by the default class loader. Attempting to access these protected variables gives an access error when the class is dynamically loaded that doesnt occur when the class is loaded at startup.
    Is there a way to make this work?

    To answer my own question -- no
    A reference from http://access1.sun.com/techarticles/DR-article.html says:
    The use of Dynamic Class Reloading can introduce problems when classes that are being dynamically reloaded make calls to non-public methods of helper classes that are in the same package. Such calls are likely to cause a java.lang.IllegalAccesserror to be thrown. This is because a class that is dynamically reloaded is loaded by a different classloader than the one used to load the helper classes. Classes that appear to be in the same package are effectively in different packages when loaded by different classloaders. If class com.myapp.MyServlet is loaded by one classloader and an instance of it tries to call a non-public method of an instance of class com.myapp.Helper loaded by a different classloader, the call will fail because the two classes are in different packages.
    So not being able to access non-private variables in this scenario is the way it works.

  • Managing constants in large applications

    This is an issue that has come up many times in my projects. While I try to avoid the practice, I almost always have some sort of Constants.java class that contains a bunch of public static final constants. This includes things like application name, filenames for configuration files, version numbers, network ports, etc. Sometimes I'll split them up into multiple classes (e.g., AppConstants.java and NetworkConstants.java).
    Is this an accepted practice in larger applications, or are global constants typically handled differently? I've always considered my solution to be inelegant, but I haven't come up with a better way of doing it. Suggestions?

    > Yes, I do typically use an interface to hold my
    constants. I know I said "class" above.
    This is considered a bad practice, or "antipattern", to wit:
    Effective Java - Joshua Bloch, Chapter 4, Item #17: Use interfaces only to define types.
    The constant interface pattern is a poor use of interfaces. That a class uses some constants internally is an implementation detail. Implementing a constant interface causes this implementation detail to leak into the class's exported API. It is of no consequence to the users of a class that the class implements a constant interface. In fact, it may even confuse them. Worse, it represents a commitment: if in a future release the class is modified so that it no longer needs to use the constants, it still must implement the interface to ensure binary compatibility. If a nonfinal class implements a constant interface, all of its subclasses will have their namespaces polluted by the constants in the interface.
    In summary, interfaces should only be used to define types. They should not be used to export constants.
    ~

Maybe you are looking for