위의 내용 처럼 Argument 값을 정규식에 대입하려면 Argument 전체 값이 필요한데, Main(string [] args)를 통해서 받은 args 값은 공백으로 전부 짤라놔서, 저 정규식을 대입해봐야 아무 도움이 안된다. 즉 자르기 전, 원본 Arguments 값을 얻어와야 한다.
일단 여기 접속하면 다양한 ActiveX나 관련 모듈들을 설치한다. 애초에 Internet Explorer를 쓰라고 나오긴 하는데, Chrome이나 Firefox에도 되긴한다. veraport-g3-x64 를 설치하면 대부분 관련된 대부분은 설치되긴 한다.
그런데, 이상하게 발급, 출력 부분에서 발급하려고 "결제", 상단에 나오는 팝업에서 "열기"를 하는 순간, RPRTRegisterXCtrl.exe 를 실행한다고 한다. 그래서 실행해! 라고 했는데.... 반응이 없다. 계속 기다려봤는데.. 역시 아무것도 동작하지 않는다.
처음에는 내 쪽에서 설정되거나 다른 프로그램과 오류가 있는줄 알았는데... 아니였다.
문제 원인
처음에는 단순 프로그램 충돌, 가상화시스템, 네트워크 ... 뭐 등등 다양한 부분에서 접근했다. 심지어 회사에서 놀고 있는 노트북이 있어서 거기다가도 했는데 동일했다. 단순 열람이나, 전자정부문서 지갑 전송 같은데서는 아무 문제가 없는데, 유독 이 "출력", "발급"에서는 터진다.
한 2시간 정도 삽질하다가.. Event Viewer를 보는데... 메시지가...
"C:\Program Files (x86)\markany\maepscourt\rprtregisterxctrl.xgd"에 대한 활성화 컨텍스트를 생성하지 못했습니다.
종속 어셈블리 Microsoft.VC90.MFC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"을(를) 찾을 수 없습니다.
자세한 진단을 위해서는 sxstrace.exe를 사용하십시오.
....
뒷골이 싸했다.
패키징 실패. 이 프린터용 프로그램인 RPRTRegisterXCtrl.exe 패키징할 때, 이에 연관된 라이브러리를 같이 설치하지 않은 것이다. 만일 사용자가 오랫동안 포멧하지 않고 사용하면서 다양한 프로그램을 깔았다면, 분명 설치되어 있을 라이브러리 겠지만, 나 같이 깔끔하게 포멧을 하고 새로 설치해서 사용하는 사람의 경우 저 라이브러리가 없을 가능성이 높은데... 이거 패키징 한 친구는 지 컴퓨터에서 잘 된다고 넘어간듯...
기존에 Yona 를 구축해서 버전관리를 잘해오고 있는데, 문제는 알림 메일이였다. 지금까지 계속 google의 SMTP로 잘 운영해오다가, 어느 순간 google의 로그인 방식이 보안 정책에 따라, OAuth 방식이 아니면 더 이상 예전 처럼 아이디/패스워드 기반의 로그인을 지원하지 않는 것이다. 그래서 naver.com 내에 계정을 하나 파서 그 안에 있는 POP3/IMAP 기능을 활성화 했고, 거기서 제공하는 SMTP 설정 값을 이용해 Yona의 application.conf 값을 아래와 같이 수정했다.
2024-03-06 13:26:51,466 - [WARN] - from application in play-akka.actor.default-dispatcher-974
Failed to send a notification: org.apache.commons.mail.HtmlEmail@1720365d
org.apache.commons.mail.EmailException: Sending the email to the following server failed : smtp.naver.com:465
at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1410)
at org.apache.commons.mail.Email.send(Email.java:1437)
at info.schleichardt.play2.mailplugin.MailPlugin$$anonfun$6.apply(MailPlugin.scala:60)
at info.schleichardt.play2.mailplugin.MailPlugin$$anonfun$6.apply(MailPlugin.scala:54)
at info.schleichardt.play2.mailplugin.MailPlugin.send(MailPlugin.scala:68)
at info.schleichardt.play2.mailplugin.api.Mailer$.send(Mailer.scala:8)
at info.schleichardt.play2.mailplugin.Mailer.send(Mailer.java:15)
at controllers.ProjectApp.sendTransferRequestMail(ProjectApp.java:775)
at controllers.ProjectApp.transferProject(ProjectApp.java:634)
at Routes$$anonfun$routes$1$$anonfun$applyOrElse$191$$anonfun$apply$191.apply(routes_routing.scala:3708)
at Routes$$anonfun$routes$1$$anonfun$applyOrElse$191$$anonfun$apply$191.apply(routes_routing.scala:3708)
at play.core.Router$HandlerInvokerFactory$$anon$4.resultCall(Router.scala:264)
at play.core.Router$HandlerInvokerFactory$JavaActionInvokerFactory$$anon$15$$anon$1.invocation(Router.scala:255)
at play.core.j.JavaAction$$anon$1.call(JavaAction.scala:55)
at Global$2.call(Global.java:274)
at actions.AnonymousCheckAction.call(AnonymousCheckAction.java:57)
at actions.IsAllowedAction.call(IsAllowedAction.java:68)
at actions.AbstractProjectCheckAction.call(AbstractProjectCheckAction.java:93)
at play.db.ebean.TransactionalAction$1.call(TransactionalAction.java:21)
at play.db.ebean.TransactionalAction$1.call(TransactionalAction.java:18)
at com.avaje.ebeaninternal.server.core.DefaultServer.execute(DefaultServer.java:715)
at com.avaje.ebeaninternal.server.core.DefaultServer.execute(DefaultServer.java:709)
at com.avaje.ebean.Ebean.execute(Ebean.java:1264)
at play.db.ebean.TransactionalAction.call(TransactionalAction.java:18)
at play.core.j.JavaAction$$anonfun$11.apply(JavaAction.scala:82)
at play.core.j.JavaAction$$anonfun$11.apply(JavaAction.scala:82)
at scala.concurrent.impl.Future$PromiseCompletingRunnable.liftedTree1$1(Future.scala:24)
at scala.concurrent.impl.Future$PromiseCompletingRunnable.run(Future.scala:24)
at play.core.j.HttpExecutionContext$$anon$2.run(HttpExecutionContext.scala:40)
at play.api.libs.iteratee.Execution$trampoline$.execute(Execution.scala:46)
at play.core.j.HttpExecutionContext.execute(HttpExecutionContext.scala:32)
at scala.concurrent.impl.Future$.apply(Future.scala:31)
at scala.concurrent.Future$.apply(Future.scala:485)
at play.core.j.JavaAction$class.apply(JavaAction.scala:82)
at play.core.Router$HandlerInvokerFactory$JavaActionInvokerFactory$$anon$15$$anon$1.apply(Router.scala:252)
at play.api.mvc.Action$$anonfun$apply$1$$anonfun$apply$4$$anonfun$apply$5.apply(Action.scala:130)
at play.api.mvc.Action$$anonfun$apply$1$$anonfun$apply$4$$anonfun$apply$5.apply(Action.scala:130)
at play.utils.Threads$.withContextClassLoader(Threads.scala:21)
at play.api.mvc.Action$$anonfun$apply$1$$anonfun$apply$4.apply(Action.scala:129)
at play.api.mvc.Action$$anonfun$apply$1$$anonfun$apply$4.apply(Action.scala:128)
at scala.Option.map(Option.scala:145)
at play.api.mvc.Action$$anonfun$apply$1.apply(Action.scala:128)
at play.api.mvc.Action$$anonfun$apply$1.apply(Action.scala:121)
at play.api.libs.iteratee.Iteratee$$anonfun$mapM$1.apply(Iteratee.scala:483)
at play.api.libs.iteratee.Iteratee$$anonfun$mapM$1.apply(Iteratee.scala:483)
at play.api.libs.iteratee.Iteratee$$anonfun$flatMapM$1.apply(Iteratee.scala:519)
at play.api.libs.iteratee.Iteratee$$anonfun$flatMapM$1.apply(Iteratee.scala:519)
at play.api.libs.iteratee.Iteratee$$anonfun$flatMap$1$$anonfun$apply$14.apply(Iteratee.scala:496)
at play.api.libs.iteratee.Iteratee$$anonfun$flatMap$1$$anonfun$apply$14.apply(Iteratee.scala:496)
at scala.concurrent.impl.Future$PromiseCompletingRunnable.liftedTree1$1(Future.scala:24)
at scala.concurrent.impl.Future$PromiseCompletingRunnable.run(Future.scala:24)
at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:41)
at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:393)
at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
Caused by: javax.mail.MessagingException: Could not connect to SMTP host: smtp.naver.com, port: 465;
nested exception is:
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1972)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:642)
at javax.mail.Service.connect(Service.java:317)
at javax.mail.Service.connect(Service.java:176)
at javax.mail.Service.connect(Service.java:125)
at javax.mail.Transport.send0(Transport.java:194)
at javax.mail.Transport.send(Transport.java:124)
at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1400)
... 56 more
Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at sun.security.ssl.HandshakeContext.<init>(HandshakeContext.java:171)
at sun.security.ssl.ClientHandshakeContext.<init>(ClientHandshakeContext.java:103)
at sun.security.ssl.TransportContext.kickstart(TransportContext.java:227)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:433)
at com.sun.mail.util.SocketFetcher.configureSSLSocket(SocketFetcher.java:548)
at com.sun.mail.util.SocketFetcher.createSocket(SocketFetcher.java:352)
at com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:207)
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1938)
... 63 more
그런데 에러를 찬찬히 살펴보니 아래와 같은 문장이 눈에 딱 띄었다.
Caused by: javax.mail.MessagingException: Could not connect to SMTP host: smtp.naver.com, port: 465;
nested exception is:
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1972)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:642)
이상해서, 과거 Yona의 Issue 창을 뒤져보니, 답글 중에 아래와 같은 답변을 발견했다.
다른 곳에서 전체 백업된 SQL을 받아 데이터베이스를 생성했는데, 생성했더니, 데이터베이스의 Data Collate가 "Latin1_General_CI_AS"로 설정되어 있었다. 그래서 간신히 데이터베이스의 설정 값을 바꾸어 "Korean_Wansung_CI_AS"으로 바꾸긴 했다. 그런데 Query를 실행하니까, 웬걸...컬럼들은 여전히 "Latin1_General_CI_AS" 로 되어 있었고, 새로 만든 테이블 내의 값들과 비교하려는데 자꾸 다음과 같은 에러메시지를 뱉어됐다.
Cannot resolve the collation conflict between "Korean_Wansung_CI_AS" and "Latin1_General_CI_AS" in the equal to operation.
데이블 디자이너, 그러니까, 테이블 수정에 들어가 varchar 컬럼마다 데이터 정렬(Data Collate) 값을 바꾸면 되긴 하는데, 이 많은 테이블의 또, 그 컬럼들에 들어가 수정하려니 깝깝했다.
아래의 코드 값에서 @collate값만 Korean_Wansung_CI_AS로 변경하고, 수정할 데이터베이스의 쿼리창을 열고 실행했다.
DECLARE @collate nvarchar(100);
DECLARE @table nvarchar(255);
DECLARE @column_name nvarchar(255);
DECLARE @column_id int;
DECLARE @data_type nvarchar(255);
DECLARE @max_length int;
DECLARE @row_id int;
DECLARE @sql nvarchar(max);
DECLARE @sql_column nvarchar(max);
SET @collate = 'Korean_Wansung_CI_AS';
DECLARE local_table_cursor CURSOR FOR
SELECT [name]
FROM sysobjects
WHERE OBJECTPROPERTY(id, N'IsUserTable') = 1
OPEN local_table_cursor
FETCH NEXT FROM local_table_cursor
INTO @table
WHILE @@FETCH_STATUS = 0
BEGIN
DECLARE local_change_cursor CURSOR FOR
SELECT ROW_NUMBER() OVER (ORDER BY c.column_id) AS row_id
, c.name column_name
, t.Name data_type
, c.max_length
, c.column_id
FROM sys.columns c
JOIN sys.types t ON c.system_type_id = t.system_type_id
LEFT OUTER JOIN sys.index_columns ic ON ic.object_id = c.object_id AND ic.column_id = c.column_id
LEFT OUTER JOIN sys.indexes i ON ic.object_id = i.object_id AND ic.index_id = i.index_id
WHERE c.object_id = OBJECT_ID(@table)
ORDER BY c.column_id
OPEN local_change_cursor
FETCH NEXT FROM local_change_cursor
INTO @row_id, @column_name, @data_type, @max_length, @column_id
WHILE @@FETCH_STATUS = 0
BEGIN
IF (@max_length = -1) OR (@max_length > 4000) SET @max_length = 4000;
IF (@data_type LIKE '%char%')
BEGIN TRY
SET @sql = 'ALTER TABLE ' + @table + ' ALTER COLUMN ' + @column_name + ' ' + @data_type + '(' + CAST(@max_length AS nvarchar(100)) + ') COLLATE ' + @collate
PRINT @sql
EXEC sp_executesql @sql
END TRY
BEGIN CATCH
PRINT 'ERROR: Some index or constraint rely on the column' + @column_name + '. No conversion possible.'
PRINT @sql
END CATCH
FETCH NEXT FROM local_change_cursor
INTO @row_id, @column_name, @data_type, @max_length, @column_id
END
CLOSE local_change_cursor
DEALLOCATE local_change_cursor
FETCH NEXT FROM local_table_cursor
INTO @table
END
CLOSE local_table_cursor
DEALLOCATE local_table_cursor
GO
현재 개인 개발 도구를 이용해서 작업 중인데, 네트워크 IP가 미묘하게 겹쳐 업무를 할 때마다 Lan 선을 뽑았다 꼈다를 반복해왔다.
개발 PC에 랜카드를 두개 붙여서 한 쪽은 192.168.30.200 으로 설정해서, 인터넷이나 버전관리 서버에 접속해서 Commit을 했고, 다른 한쪽에는 192.168.0.105 으로 설정한 뒤, Lab 실에 있는 장비와 연결을 했다.
인터넷 하면서 Lab 실 장비를 건드릴 때는 문제가 없는데, 딱! 버전관리 서버를 손대자 문제가 터져나갔다. 그 이유가 192.168.0.x 대역을 버전관리 서버와 Lab실이 동시에 이용해서 이다. 만일 버전관리 서버와 연결하고 싶으면 Lab 실과 연결된 네트워크 랜선을 떼어야 하고, 다시 Lab 장비를 손대려면 다시 붙여야 한다. 만일 Lab 실 장비 손 보다가, 소스 수정할 내용을 Commit을 하고 싶으면 다시 뗀것을 붙여야 했다.
한 두번은 하겠는데, Commit 되는 횟수가 늘어나면 늘어날 수록 점점 귀차니즘이 돌발했다.
그래서 방법을 바꿨다. 그래서 route 라는 명령을 찾게 되었다.
route는 현재 네트워크를 호출할 때 어디로 연결해서 처리할지를 나타내고 수정하는 도구다. 먼저 관리자 권한으로 터미널(관리자)를 연다.
그리고 다음과 같이 명령을 입력하면 현재 설정된 라우팅 정보가 보인다.
저 라우팅 테이블의 내용만 보면, 0.0.0.0 즉 모든 연결은 192.168.30.200 인터페이스에 있는 192.168.30.1 게이트웨이로 보낸다는 의미다. 그리고 192.168.0.0 즉 192.168.0.x 로 된 모든 연결은 192.168.0.105 인터페이스로 보낸다는 의미다.
이걸 보고 해석을 하면, 192.168.30.63 하면, 192.168.30.200 인터페이스를 통해 패킷을 보내고, 192.168.0.3 하면, 192.168.0.105 인터페이스를 통해 패킷을 보낸다.
문제는 192.168.0.2 를 했을 때도, 192.168.0.105를 통해 내보낸다. 내 버전관리 서버는 192.168.30.200을 통해서 VPN을 거쳐 접속을 해야 하는데도 말이다.
192.168.0.2 의 연결에서 Subnet mask를 255.255.255.255를 하면, 딱 저 IP를 입력할 때, 192.168.30.200 인터페이스로 패킷을 보내라는 명령이다. 일단 Subnet mask 부분에서 이해의 폭을 너무 많이 요구하긴 하지만, 최소한 맨 앞의 값과 255.255.255.255 가 붙으면 1개의 IP 라고 읽자. 192.168.0.3 이나 192.168.0.100 같은 경우에는 라우팅 테이블 상에 있는 192.168.0.0 / 255.255.255.0 에 걸려 192.168.0.105 인터페이스로 패킷을 보내지만, 192.168.0.2 는 192.168.0.2 / 255.255.255.255 에 걸려서 192.168.30.200 인터페이스로 패킷을 보낸다고 이해하면 된다. 여기서 인터페이스 라는게 랜카드를 의미하고, 그 랜카드에 설정된 IP 주소라고 읽으면 된다.
맨 마지막의 -p는 영구 연결이라고 해서 네트워크가 리셋되도 일단 살아 있게 만들어 준거다. 없으면 나중에 네트워크 리셋되는 순간 위의 명령만 다시 넣어주면 된다.
나중에 vpn을 통해 이용해야 할 서버의 IP 192.168.0.88 라는게 생기고, 지금과 같이 하고 싶다면, 위의 명령을 이용해서 만들어 줄 수 있다.
