On Mar 26, 2013, at 4:07 PM, André Warnier wrote:
Patrick Flaherty wrote:
On Mar 25, 2013, at 1:15 PM, Howard W. Smith, Jr. wrote:
On Mon, Mar 25, 2013 at 11:14 AM, Patrick Flaherty
<pflah...@rampageinc.com>wrote:
Update: If I'm login interactively (meaning machine boots and I
login and
get my desktop) and that interactive account matches the service
login
account
then "net use" from within the service does return all mapped
drives.
I expected as much. It seems as though you cannot get away from the
requirement of having to login 'first'...to get everything working
as
designed/expected in your app.
Excuse me, if I missed the business requirement specification
(earlier in
this conversation), but is the requirement only to get a list of
mapped
drives for 'your' user login or any enduser that logs into the
production
server/client/PC/machine?
can you add the list of network drives to a database table, and
maintain
the database table and retrieve the list from that database table
via the
tomcat-app-running-as-service?
if you only need a list of mapped network drives for your user
login, can
you just maintain a 'file' that has this list on the target/
production
server, and whenever it changes, can you update the file, and make
the
topcat-app-running-as-service to always read the file instead of
having to
call 'net use'?
IMHO and FWIW, i would never go with the approach of relying on a
windows
'command line' to do this/that for me. yes, in my app, i allow
endusers to
update files/documents, and the app saves the files/documents to a
certain
folder on the server, and my app will list those files on a web
page, and
they can view/download those files from/via the web app... all
that is done
via java instead of doing a 'cmd.exe dir'. i'm new to java, always
wanted
to be java developer, and loving what i can do with java. i'm almost
getting to the point, where my days of a 'windows user' are
done... one
day, i hope to migrate to linux for target server instead of windows
server. :)
This is what I see. If my service logs in as "service-user" and I
login normally to my desktop as "dt-user".
I call "net use" from my service and get an empty list. Now I
logout as "dt-user"and login as "service-user" and I mapped
4 drives and only 2 of the drives are mapped persisted (i.e.
reconnect at logon). I logout as "service-user" and
now I have my app call "net use" programatically and it returns the
2 drives that were mapped with persistence.
Conclusion: Whatever drives are mapped persisted when logged in as
the user the service logs in as, then your
app can call "net use" and get those drives returned from "net use"
even if your logged in as "dt-user" OR nobody
is logged in at all !!!!
Maybe someone can confirm my finding, but this is what I see.
Hi Patrick.
Basically, what Jeffrey and I are trying to tell you :
- we are not saying that your observations above are incorrect, in
the context in which you are making them
- but it seems to us that the way you are going about this, is not
the right way to make your application portable to other systems or
Windows versions, because it seems to rely on things that may be
particular to one or the other Windows version or circumstance.
In other words, it makes your application "fragile".
The point is : when you login interactively to a Windows computer as
"user-1", or when you run a Service which logs-in to that computer
as the same "user-1", the environment in each case is *different* in
many ways. It may be that under one or more particular versions of
Windows, when comparing certain particular aspects (like prior drive
mappings), you cannot see a difference. But differences there are,
and they may show up on another version of Windows that you have not
tried yet, or maybe with the same version somewhere else which has
other "network policies" or "security policies" than the ones you
are testing under right now.
If you totally control your environment, notice that something is
working and are happy with that because you are never going to use
this anywhere else, then that's fine, keep doing it and don't spend
more time figuring out what may be or not portable somewhere else.
But if you want to make something portable, then you have to take
into account that, for example, the host on which your app may be
running one day, will not allow you to login interactively ahead of
time to make drive mappings for the service's user-id.
For example, because the sysadmins have decided that anything that
runs as a service needs a special "service account" (which,
contrarily to all the others has a password that never runs out
e.g.); but on the other hand, according to their organisation's
rules, a service account can *not* be used to login interactively
anywhere. And since this rule already applies to the 10,000
workstations and servers of that organisation, they are not going to
change it just for you.
And I believe that now, we are really far from any topic that
relates to the Tomcat-specific help that is the point of this
mailing list.
Hi Andre,
You are absolutely right. This is not 100% guaranteed to be future
proof. The cases you layout are enlightening. I'm not sure we will
go this route with all the potential pitfalls we could hit in the
future. We are rethinking this now.
Thanks again.
Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
