Jump to content

techiebrandon

Members
  • Posts

    6
  • Joined

  • Last visited

techiebrandon's Achievements

Rookie

Rookie (2/14)

  • Week One Done
  • One Month Later
  • One Year In
  • First Post Rare
  • Conversation Starter Rare

Recent Badges

0

Reputation

  1. A reference would be more useful than a suggestion to search another forum.
  2. Found this to be an issue with JasperServer 3.0 when table columns are of type varchar2. JasperServer does not understand this column type, must create custom view for JS to see columns.
  3. I am working with JasperServer Pro 3.0.0, working through my first Ad hoc reports. I have some tables specified in the database which the domain engine does not seem to see completely, and I cannot find any documentation to suggest why. My tables have many columns; two of which, NAME and DESCRIPTION, that are not visible or usable when creating the Domain component to be used during the creation of the ad hoc report. I tried to continue forward with the creation, assuming that these were special keyword columns in JasperServer and maybe a join on them was not acceptable, however when picking the measure and group during the final stages of ad hoc report creation they are still not accessible. I can query the DB directly and get all my columns, and in other jrxml-based reports I can query using these fields. I am at a loss as to what I am doing wrong, any direction or references are welcome!
  4. I'll give this a go, appreciate the response and will post later next week after I test. Warm Regards
  5. I do sincerely appreciate your response, however I will still need to do a new build for each and every end-client, knowing their configuration prior to the build, and any changes to their configuration require a new build or a manual modification of a crucial file which is not something I am willing to require of my clients. Their technical skill requirements to use my product should be as close to null as possible; though this is easy enough for you or I an client could potentially see this as a major hurdle. Looking across the boards at all the mistakes technical people are making when modifying this file (when they have excellent instructions already provided), I can only imagine someone with no technical background trying to make these changes and the level of frustration. I think it would not require a huge number of cycles to make some sort of adjustment on my installer but we are still left with the scenario of the client's mail server settings changing causing failure. Again, I do appreciate your well thought out, investigated, and exampled response. I do wish it was the silver bullet for this issue. I will certainly end up making a enhancement/feature request if nothing else comes up that meets these requirements outlined. For me, Ideal solution is acceptance of system/environment variables for these properties and/or configuration exposed in the JS webapp GUI. Of course I am open to other brillant ideas? :) Again, Any redirection, clarification, and suggestions are welcome.
  6. I am working with JasperServer (Pro) 3.0 and have come across a major pain point as an ISV using the current scheduling and mail functionality provided. As an ISV each end-client I sell to will likely have their own mail server settings; with the current setup I have to modify the /jasperserver-pro/WEB_INF/js.quartz.properties file by hand to specify the end-clients mail server, username, password. This is a level of configuration that should be available via the JS webapp GUI or at least accept environment variables to set these properties prior to the start of the webserver instance. I have tried setting these properties using both CATALINA_OPTS and JAVA_OPTS with no luck, have I missed something? Is there a enterprise solution already available? I can create my own scripts to parse/modify the file after deployment and restart the server instance but this seems like a major pain point that any ISV will run into and I would expect JS (pro) to already have a ready solution to this issue. The idea is not to make custom scripts, hacks for JS so that migration from release to another does not take intimate knowledge of our hacked JS and we can move forward with minimal testing of the enterprise ready JS Pro and not devote significant cycles on a product we are leveraging. Command line attempts on Windows include: set CATALINA_OPTS=-Dreport.scheduler.mail.sender.host=mail.myhost.com set CATALINA_OPTS="-Dreport.scheduler.mail.sender.host=mail.myhost.com" set JAVA_OPTS=-Dreport.scheduler.mail.sender.host=mail.myhost.com set JAVA_OPTS="-Dreport.scheduler.mail.sender.host=mail.myhost.com" None of these properties were used during my testing to send a report via the mail server. Any redirection, clarification, and suggestions are welcome.
×
×
  • Create New...