I need to disable basic auth on weblogic server, which can be done by adding <enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credentials> into config.xml in a weblogic domain.
I'm deploying a web service to weblogic directly from IntelliJ Idea and every time I start deploy, the config.xml is replaced by a new one, so I cannot change config manually. I guess I need to pass some extra arguments in IntelliJ's run configuration. Does anyone has any experiences with this?
It was my mistake. I tried to modify config.xml and forgot my server is still running. According to this page I think it's pretty obvious why this happens. So, it has nothing to do with IntelliJ Idea.
Caution: Do not edit configuration files for a domain that is
currently running. Because Oracle WebLogic Server rewrites the files
periodically, your changes will be lost. Depending on your platform,
you also could cause Oracle WebLogic Server failures.
i need to be able to configure JBOSS as 7.2 to only startup the services required in the project.
what is the best aproach to customize JBOSS as 7.2 configuration and set it to a user defined configuration ?
i'm intending to use :
JAAS , EJB , JSF ..
If I understand your request correctly,
it would be removing the unnecessary subsystems.
In standalone, you can configure multiple xmls per your use, and decide the standalone config to use at startup, which would allow you to adapt to various needs quickly.
In domain, it's even easier as you can define various profiles, each of them with specific subsystems present or not, and then assign the necessary profile to your server group.
Removing subsystems through xml modification or CLI is simple,
adding them through CLI sometimes require figuring some of the "default" expected entries for recreation of the subsystems, but once figured out, is easy also.
Key element in your case is to make sure you do not clean up too many of the subsystems, as they sometimes have dependencies to one another.
I need a little help from you.
I have to migrate several applications from WAS 7 to WAS 8.5 with a script in Jython using wsadmin. The thing is that on WAS 7 there are a lot of Datasources and i only need to import the Datasources that are used by the applications that i have to migrate.
Long story short: i have to get the datasource properties for a specific application.
Thanks for your help!
UPDATE: After this I have to install the applications using the exported properties of datasources.
If your application developers were smart enough to use resource references, you can find JNDI names of the Datasources used by the application in the web admin console Applications > applicationName > Resource References. If not, you will have to somehow learn what the datasources are (application documentation, developers, sources). There is no other way than references to know datasources used by given app.
Then I'd suggest you to use Property files wsadmin commands to extract relevant information from one environment and apply to the other. (Or just give you datasources configuration for use in jython scripts).
If don't want to use Property files commands you can use command assistance in the console to help you create jython files, or use some already provide Jython script library
For details see:
Using properties files to manage system configuration
Accessing command assistance from the administrative console
JDBC configuration scripts (library)
I am currently working on Axis2 deployed on Resin 3.1.3. However, I got the below error during deployment:
org.apache.axis2.deployment.DeploymentException: The "Dispatch" phase is not found on the global "InFlow" phase of the axis2.xml file. Make sure the phase is within the axis2.xml file.
Any idea how to resolve this? Thanks in advance for your valuable help.
-Angel
Have a look at this page, underneath the "Phase Order" heading. That should let you know how you need to define the Dispatch phase in your axis2.xml.
It's also possible that the axis2.xml file can't be found or is missing. You haven't provided many details so it's hard to be more specific than that.
Edit:
Remember that Axis2 is a standalone web application that is deployed into a servlet container.
You indicated in your comments that you modified your web application's web.xml. You should not need to do that to get Axis2 to work properly, so you can remove those mappings and redeploy your applications.
Try this guide. Make sure that you can see the "Axis2 Happiness" page described in step 6.
Once you have that working, you can go back to your other web applications and start modifying them to call your web services.
Where would you write an error log file, say ErrorLog.txt, in Windows? Keep in mind the path would need to be open to basic users for file write permissions.
I know the eventlog is a possible location for writing errors, but does it work for "user" level permissions?
EDIT: I am targeting Windows 2003, but I was posing the question in such a way as to have a "General Guideline" for where to write error logs.
As for the EventLog, I have had issues before in an ASP.NET application where I wanted to log to the Windows event log, but I had security issues causing me heartache. (I do not recall the issues I had, but remember having them.)
Have you considered logging the event viewer instead? If you want to write your own log, I suggest the users local app setting directory. Make a product directory under there. It's different on different version of Windows.
On Vista, you cannot put files like this under c:\program files. You will run into a lot of problems with it.
In .NET, you can find out this folder with this:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
And the Event Log is fairly simple to use too:
http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog.aspx
Text files are great for a server application (you did say Windows 2003). You should have a separate log file for each server application, the location is really a matter of convention to agree with administrators. E.g. for ASP.NET apps I've often seen them placed on a separate disk from the application under a folder structure that mimics the virtual directory structure.
For client apps, one disadvantage of text files is that a user may start multiple copies of your application (unless you've taken specific steps to prevent this). So you have the problem of contention if multiple instances attempt to write to the same log file. For this reason I would always prefer the Windows Event Log for client apps. One caveat is that you need to be an administrator to create an event log - this can be done e.g. by the setup package.
If you do use a file, I'd suggest using the folder Environment.SpecialFolder.LocalApplicationData rather than SpecialFolder.ApplicationData as suggested by others. LocalApplicationData is on the local disk: you don't want network problems to stop you from logging when the user has a roaming profile. For a WinForms application, use Application.LocalUserAppDataPath.
In either case, I would use a configuration file to decide where to log, so that you can easily change it. E.g. if you use Log4Net or a similar framework, you can easily configure whether to log to a text file, event log, both or elsewhere (e.g. a database) without changing your app.
The standard location(s) are:
C:\Documents and Settings\All Users\Application Data\MyApp
or
C:\Documents and Settings\%Username%\Application Data\MyApp
(aka %UserProfile%\Application Data\MyApp) which would match your user level permission requirement. It also separates logs created by different users.
Using .NET runtime, these can be built as:
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
or
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
followed by:
MyAppDir = IO.Path.Combine(AppDir,'MyApp')
(Which, hopefully, maps Vista profiles too).
Personally, I would suggest using the Windows event log, it's great. If you can't, then write the file to the ApplicationData directory or the ProgramData (Application Data for all users on Windows XP) directory.
The Windows event log is definitely the way to go for logging of errors. You're not limited to the "Application" log as it's possible to create a new log target (e.g. "My Application"). That may need to be done as part of setup as I'm not sure if it requires administrative privileges or not. There's a Microsoft example in C# at http://support.microsoft.com/kb/307024.
Windows 2008 also has Event Log Forwarding which can be quite handy with server applications.
I agree with Lou on this, but I prefer to set this up in a configuration file like Joe said. You can use
file value="${APPDATA}/Test/log-file.txt"
("Test" could be whatever you want, or removed entirely) in the configuration file, which causes the log file to be written to "/Documents and Settings/LoginUser/Application
Data/Test" on Windows XP and to "/Users/LoginUser/AppData/Roaming/Test on Windows Vista.
I am just adding this as I just spent way too much time figuring how to make this work on Windows Vista...
This works as-is with Windows applications. To use logging in web applications, I found Phil Haack's blog entry on this to be a great resource:
http://haacked.com/archive/2005/03/07/ConfiguringLog4NetForWebApplications.aspx
%TEMP% is always a good location for logs I find.
Going against the grain here - it depends on what you need to do. Sometimes you need to manipulate the results, so log.txt is the way to go. It's simple, mutable, and easy to search.
Take an example from Joel. Fogbugz will send a log / dump of error messages via http to their server. You could do the same and not have to worry about the user's access rights on their drive.
I personally don't like to use the Windows Event Log where I am right now because we do not have access to the production servers, so that would mean that we would need to request access every time we wanted to look at the errors. It is not a speedy process unfortunately, so your troubleshooting is completely haulted by waiting for someone else. I also don't like that they kind of get lost within the ones from other applications. Sure you can sort, but it's just a bit of a nucance scrolling down. What you use will end up being a combination of personal preference coupled along with limitations of the enviroment you are working in. (log file, event log, or database)
Put it in the directory of the application. The users will need access to the folder to run and execute the application, and you can check write access on application startup.
The event log is a pain to use for troubleshooting, but you should still post significant errors there.
EDIT - You should look into the MS Application Blocks for logging if you are using .NET. They really make life easy.
Jeez Karma-killers. Next time I won't even offer a suggestion when the poster puts up an incomplete post.