[jira] [Commented] (ATLAS-1218) Atlas says it is started but does not accept REST requests
[
https://issues.apache.org/jira/browse/ATLAS-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16105227#comment-16105227
]
Richard Ding commented on ATLAS-1218:
-
[~jonesn], I like the idea of having atlas_start script wait until server is
ready. In fact, atlas_stop script uses _wait_for_shutdown_ function to wait
until the server is gone. The attached patch implements a _wait_for_startup_
function.
Here are the output of atlas_start and atlas_stop script:
{code}
starting atlas on port 21000
Apache Atlas Server started!!!
{code}
and
{code}
stopping atlas
Apache Atlas Server stopped!!!
{code}
> Atlas says it is started but does not accept REST requests
> --
>
> Key: ATLAS-1218
> URL: https://issues.apache.org/jira/browse/ATLAS-1218
> Project: Atlas
> Issue Type: Bug
>Reporter: David Radley
>
> I start Atlas on the command line and it tells me is started - but REST
> requests are not accepted immediately. There appears to be asynchronous
> background processes that have not yet initialized. I feel that when Atlas
> says it is started it should be open for business and accept REST requests.
> a few seconds later REST requests are accepted.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (ATLAS-1218) Atlas says it is started but does not accept REST requests
[ https://issues.apache.org/jira/browse/ATLAS-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding reassigned ATLAS-1218: --- Assignee: Richard Ding > Atlas says it is started but does not accept REST requests > -- > > Key: ATLAS-1218 > URL: https://issues.apache.org/jira/browse/ATLAS-1218 > Project: Atlas > Issue Type: Bug >Reporter: David Radley >Assignee: Richard Ding > Attachments: ATLAS-1218.patch > > > I start Atlas on the command line and it tells me is started - but REST > requests are not accepted immediately. There appears to be asynchronous > background processes that have not yet initialized. I feel that when Atlas > says it is started it should be open for business and accept REST requests. > a few seconds later REST requests are accepted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ATLAS-1218) Atlas says it is started but does not accept REST requests
[ https://issues.apache.org/jira/browse/ATLAS-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding updated ATLAS-1218: Attachment: ATLAS-1218.patch > Atlas says it is started but does not accept REST requests > -- > > Key: ATLAS-1218 > URL: https://issues.apache.org/jira/browse/ATLAS-1218 > Project: Atlas > Issue Type: Bug >Reporter: David Radley > Attachments: ATLAS-1218.patch > > > I start Atlas on the command line and it tells me is started - but REST > requests are not accepted immediately. There appears to be asynchronous > background processes that have not yet initialized. I feel that when Atlas > says it is started it should be open for business and accept REST requests. > a few seconds later REST requests are accepted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ATLAS-2003) Add Javadoc format to class summaries
Richard Ding created ATLAS-2003: --- Summary: Add Javadoc format to class summaries Key: ATLAS-2003 URL: https://issues.apache.org/jira/browse/ATLAS-2003 Project: Atlas Issue Type: Improvement Affects Versions: 0.8-incubating Reporter: Richard Ding Assignee: Richard Ding Priority: Minor Java class summary needs to be formatted with HTML tags so that the generated Javadoc can be properly displayed in browsers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ATLAS-2003) Add Javadoc format to class summaries
[ https://issues.apache.org/jira/browse/ATLAS-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding updated ATLAS-2003: Attachment: ATLAS-2003.patch This patch added HTML format to several Java Class summaries so that the generated Javadoc is displayed properly in browsers. > Add Javadoc format to class summaries > - > > Key: ATLAS-2003 > URL: https://issues.apache.org/jira/browse/ATLAS-2003 > Project: Atlas > Issue Type: Improvement >Affects Versions: 0.8-incubating >Reporter: Richard Ding >Assignee: Richard Ding >Priority: Minor > Attachments: ATLAS-2003.patch > > > Java class summary needs to be formatted with HTML tags so that the generated > Javadoc can be properly displayed in browsers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ATLAS-2003) Add Javadoc format to class summaries
[ https://issues.apache.org/jira/browse/ATLAS-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding updated ATLAS-2003: Fix Version/s: 0.9-incubating > Add Javadoc format to class summaries > - > > Key: ATLAS-2003 > URL: https://issues.apache.org/jira/browse/ATLAS-2003 > Project: Atlas > Issue Type: Improvement >Affects Versions: 0.8-incubating >Reporter: Richard Ding >Assignee: Richard Ding >Priority: Minor > Fix For: 0.9-incubating > > Attachments: ATLAS-2003.patch > > > Java class summary needs to be formatted with HTML tags so that the generated > Javadoc can be properly displayed in browsers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ATLAS-2004) Move Apache license header to the beginning of file
Richard Ding created ATLAS-2004: --- Summary: Move Apache license header to the beginning of file Key: ATLAS-2004 URL: https://issues.apache.org/jira/browse/ATLAS-2004 Project: Atlas Issue Type: Improvement Affects Versions: 0.8-incubating Reporter: Richard Ding Assignee: Richard Ding Priority: Trivial Fix For: 0.9-incubating The Apache license header is not at the beginning of _AtlasKafkaMessage.java_ and the header shows up in the generated Javadoc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ATLAS-2004) Move Apache license header to the beginning of file
[ https://issues.apache.org/jira/browse/ATLAS-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding updated ATLAS-2004: Attachment: ATLAS-2004.patch > Move Apache license header to the beginning of file > --- > > Key: ATLAS-2004 > URL: https://issues.apache.org/jira/browse/ATLAS-2004 > Project: Atlas > Issue Type: Improvement >Affects Versions: 0.8-incubating >Reporter: Richard Ding >Assignee: Richard Ding >Priority: Trivial > Fix For: 0.9-incubating > > Attachments: ATLAS-2004.patch > > > The Apache license header is not at the beginning of _AtlasKafkaMessage.java_ > and the header shows up in the generated Javadoc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ATLAS-1867) org.apache.atlas.AtlasClientV2.deleteAtlasTypeDefs gives an exception
[ https://issues.apache.org/jira/browse/ATLAS-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding updated ATLAS-1867: Affects Version/s: 0.8-incubating > org.apache.atlas.AtlasClientV2.deleteAtlasTypeDefs gives an exception > - > > Key: ATLAS-1867 > URL: https://issues.apache.org/jira/browse/ATLAS-1867 > Project: Atlas > Issue Type: Bug >Affects Versions: 0.8-incubating >Reporter: David Radley > > The org.apache.atlas.AtlasClientV2 is the Java API for Atlas. As such the > helper methods in it are the API. calling deleteAtlasTypeDefs gives the > exception > Exception in thread "main" com.sun.jersey.api.client.ClientHandlerException: > java.net.ProtocolException: HTTP method DELETE doesn't support output > at > com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:155) > at > com.sun.jersey.api.client.filter.HTTPBasicAuthFilter.handle(HTTPBasicAuthFilter.java:105) > at com.sun.jersey.api.client.Client.handle(Client.java:652) > at com.sun.jersey.api.client.WebResource.handle(WebResource.java:682) > at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74) > at > com.sun.jersey.api.client.WebResource$Builder.method(WebResource.java:634) > at > org.apache.atlas.AtlasBaseClient.callAPIWithResource(AtlasBaseClient.java:298) > at > org.apache.atlas.AtlasBaseClient.callAPIWithResource(AtlasBaseClient.java:285) > at org.apache.atlas.AtlasBaseClient.callAPI(AtlasBaseClient.java:427) > at > org.apache.atlas.AtlasClientV2.deleteAtlasTypeDefs(AtlasClientV2.java:258) > at > org.apache.atlas.examples.DeleteTypesFromJsonFileUtil.runTypeDelete(DeleteTypesFromJsonFileUtil.java:73) > at > org.apache.atlas.examples.DeleteTypesFromJsonFileUtil.main(DeleteTypesFromJsonFileUtil.java:58) > Caused by: java.net.ProtocolException: HTTP method DELETE doesn't support > output > at > sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1083) > at > com.sun.jersey.client.urlconnection.URLConnectionClientHandler$1$1.getOutputStream(URLConnectionClientHandler.java:238) > at > com.sun.jersey.api.client.CommittingOutputStream.commitStream(CommittingOutputStream.java:117) > at > com.sun.jersey.api.client.CommittingOutputStream.write(CommittingOutputStream.java:89) > at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) > at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) > at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) > at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) > at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) > at java.io.BufferedWriter.flush(BufferedWriter.java:254) > at > com.sun.jersey.core.util.ReaderWriter.writeToAsString(ReaderWriter.java:191) > at > com.sun.jersey.core.provider.AbstractMessageReaderWriterProvider.writeToAsString(AbstractMessageReaderWriterProvider.java:128) > at > com.sun.jersey.core.impl.provider.entity.StringProvider.writeTo(StringProvider.java:88) > at > com.sun.jersey.core.impl.provider.entity.StringProvider.writeTo(StringProvider.java:58) > at > com.sun.jersey.api.client.RequestWriter.writeRequestEntity(RequestWriter.java:300) > at > com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:217) > at > com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:153) > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ATLAS-1867) org.apache.atlas.AtlasClientV2.deleteAtlasTypeDefs gives an exception
[ https://issues.apache.org/jira/browse/ATLAS-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding reassigned ATLAS-1867: --- Assignee: Richard Ding > org.apache.atlas.AtlasClientV2.deleteAtlasTypeDefs gives an exception > - > > Key: ATLAS-1867 > URL: https://issues.apache.org/jira/browse/ATLAS-1867 > Project: Atlas > Issue Type: Bug >Affects Versions: 0.8-incubating >Reporter: David Radley >Assignee: Richard Ding > > The org.apache.atlas.AtlasClientV2 is the Java API for Atlas. As such the > helper methods in it are the API. calling deleteAtlasTypeDefs gives the > exception > Exception in thread "main" com.sun.jersey.api.client.ClientHandlerException: > java.net.ProtocolException: HTTP method DELETE doesn't support output > at > com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:155) > at > com.sun.jersey.api.client.filter.HTTPBasicAuthFilter.handle(HTTPBasicAuthFilter.java:105) > at com.sun.jersey.api.client.Client.handle(Client.java:652) > at com.sun.jersey.api.client.WebResource.handle(WebResource.java:682) > at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74) > at > com.sun.jersey.api.client.WebResource$Builder.method(WebResource.java:634) > at > org.apache.atlas.AtlasBaseClient.callAPIWithResource(AtlasBaseClient.java:298) > at > org.apache.atlas.AtlasBaseClient.callAPIWithResource(AtlasBaseClient.java:285) > at org.apache.atlas.AtlasBaseClient.callAPI(AtlasBaseClient.java:427) > at > org.apache.atlas.AtlasClientV2.deleteAtlasTypeDefs(AtlasClientV2.java:258) > at > org.apache.atlas.examples.DeleteTypesFromJsonFileUtil.runTypeDelete(DeleteTypesFromJsonFileUtil.java:73) > at > org.apache.atlas.examples.DeleteTypesFromJsonFileUtil.main(DeleteTypesFromJsonFileUtil.java:58) > Caused by: java.net.ProtocolException: HTTP method DELETE doesn't support > output > at > sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1083) > at > com.sun.jersey.client.urlconnection.URLConnectionClientHandler$1$1.getOutputStream(URLConnectionClientHandler.java:238) > at > com.sun.jersey.api.client.CommittingOutputStream.commitStream(CommittingOutputStream.java:117) > at > com.sun.jersey.api.client.CommittingOutputStream.write(CommittingOutputStream.java:89) > at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) > at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) > at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) > at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) > at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) > at java.io.BufferedWriter.flush(BufferedWriter.java:254) > at > com.sun.jersey.core.util.ReaderWriter.writeToAsString(ReaderWriter.java:191) > at > com.sun.jersey.core.provider.AbstractMessageReaderWriterProvider.writeToAsString(AbstractMessageReaderWriterProvider.java:128) > at > com.sun.jersey.core.impl.provider.entity.StringProvider.writeTo(StringProvider.java:88) > at > com.sun.jersey.core.impl.provider.entity.StringProvider.writeTo(StringProvider.java:58) > at > com.sun.jersey.api.client.RequestWriter.writeRequestEntity(RequestWriter.java:300) > at > com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:217) > at > com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:153) > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ATLAS-1867) org.apache.atlas.AtlasClientV2.deleteAtlasTypeDefs gives an exception
[
https://issues.apache.org/jira/browse/ATLAS-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16109432#comment-16109432
]
Richard Ding commented on ATLAS-1867:
-
The exception I got is
{code}
Exception in thread "main" com.sun.jersey.api.client.UniformInterfaceException:
DELETE http://localhost:31000/api/atlas/v2/types/typedefs/ returned a response
status of 204 No Content
at
com.sun.jersey.api.client.ClientResponse.getEntity(ClientResponse.java:609)
at
com.sun.jersey.api.client.ClientResponse.getEntity(ClientResponse.java:586)
at
org.apache.atlas.AtlasServiceException.(AtlasServiceException.java:65)
at
org.apache.atlas.AtlasBaseClient.callAPIWithResource(AtlasBaseClient.java:356)
at
org.apache.atlas.AtlasBaseClient.callAPIWithResource(AtlasBaseClient.java:296)
at org.apache.atlas.AtlasBaseClient.callAPI(AtlasBaseClient.java:448)
at
org.apache.atlas.AtlasClientV2.deleteAtlasTypeDefs(AtlasClientV2.java:281)
{code}
It appears that the server returns successfully with "204 No Content" but
client can only handle "200 OK" response code.
> org.apache.atlas.AtlasClientV2.deleteAtlasTypeDefs gives an exception
> -
>
> Key: ATLAS-1867
> URL: https://issues.apache.org/jira/browse/ATLAS-1867
> Project: Atlas
> Issue Type: Bug
>Affects Versions: 0.8-incubating
>Reporter: David Radley
>Assignee: Richard Ding
>
> The org.apache.atlas.AtlasClientV2 is the Java API for Atlas. As such the
> helper methods in it are the API. calling deleteAtlasTypeDefs gives the
> exception
> Exception in thread "main" com.sun.jersey.api.client.ClientHandlerException:
> java.net.ProtocolException: HTTP method DELETE doesn't support output
> at
> com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:155)
> at
> com.sun.jersey.api.client.filter.HTTPBasicAuthFilter.handle(HTTPBasicAuthFilter.java:105)
> at com.sun.jersey.api.client.Client.handle(Client.java:652)
> at com.sun.jersey.api.client.WebResource.handle(WebResource.java:682)
> at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
> at
> com.sun.jersey.api.client.WebResource$Builder.method(WebResource.java:634)
> at
> org.apache.atlas.AtlasBaseClient.callAPIWithResource(AtlasBaseClient.java:298)
> at
> org.apache.atlas.AtlasBaseClient.callAPIWithResource(AtlasBaseClient.java:285)
> at org.apache.atlas.AtlasBaseClient.callAPI(AtlasBaseClient.java:427)
> at
> org.apache.atlas.AtlasClientV2.deleteAtlasTypeDefs(AtlasClientV2.java:258)
> at
> org.apache.atlas.examples.DeleteTypesFromJsonFileUtil.runTypeDelete(DeleteTypesFromJsonFileUtil.java:73)
> at
> org.apache.atlas.examples.DeleteTypesFromJsonFileUtil.main(DeleteTypesFromJsonFileUtil.java:58)
> Caused by: java.net.ProtocolException: HTTP method DELETE doesn't support
> output
> at
> sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1083)
> at
> com.sun.jersey.client.urlconnection.URLConnectionClientHandler$1$1.getOutputStream(URLConnectionClientHandler.java:238)
> at
> com.sun.jersey.api.client.CommittingOutputStream.commitStream(CommittingOutputStream.java:117)
> at
> com.sun.jersey.api.client.CommittingOutputStream.write(CommittingOutputStream.java:89)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at java.io.BufferedWriter.flush(BufferedWriter.java:254)
> at
> com.sun.jersey.core.util.ReaderWriter.writeToAsString(ReaderWriter.java:191)
> at
> com.sun.jersey.core.provider.AbstractMessageReaderWriterProvider.writeToAsString(AbstractMessageReaderWriterProvider.java:128)
> at
> com.sun.jersey.core.impl.provider.entity.StringProvider.writeTo(StringProvider.java:88)
> at
> com.sun.jersey.core.impl.provider.entity.StringProvider.writeTo(StringProvider.java:58)
> at
> com.sun.jersey.api.client.RequestWriter.writeRequestEntity(RequestWriter.java:300)
> at
> com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:217)
> at
> com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:153)
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ATLAS-1867) org.apache.atlas.AtlasClientV2.deleteAtlasTypeDefs gives an exception
[
https://issues.apache.org/jira/browse/ATLAS-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Ding updated ATLAS-1867:
Attachment: ATLAS-1867.patch
According to the Javadoc on the REST endpoint:
{quote}
/**
* Bulk delete API for all types
* @param typesDef A composite object that captures all types to be deleted
* @throws Exception
* @HTTP 204 On successful deletion of the requested type definitions
* @HTTP 400 On validation failure for any type definitions
*/
{quote}
The patch changes the response code on the client side.
> org.apache.atlas.AtlasClientV2.deleteAtlasTypeDefs gives an exception
> -
>
> Key: ATLAS-1867
> URL: https://issues.apache.org/jira/browse/ATLAS-1867
> Project: Atlas
> Issue Type: Bug
>Affects Versions: 0.8-incubating
>Reporter: David Radley
>Assignee: Richard Ding
> Attachments: ATLAS-1867.patch
>
>
> The org.apache.atlas.AtlasClientV2 is the Java API for Atlas. As such the
> helper methods in it are the API. calling deleteAtlasTypeDefs gives the
> exception
> Exception in thread "main" com.sun.jersey.api.client.ClientHandlerException:
> java.net.ProtocolException: HTTP method DELETE doesn't support output
> at
> com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:155)
> at
> com.sun.jersey.api.client.filter.HTTPBasicAuthFilter.handle(HTTPBasicAuthFilter.java:105)
> at com.sun.jersey.api.client.Client.handle(Client.java:652)
> at com.sun.jersey.api.client.WebResource.handle(WebResource.java:682)
> at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
> at
> com.sun.jersey.api.client.WebResource$Builder.method(WebResource.java:634)
> at
> org.apache.atlas.AtlasBaseClient.callAPIWithResource(AtlasBaseClient.java:298)
> at
> org.apache.atlas.AtlasBaseClient.callAPIWithResource(AtlasBaseClient.java:285)
> at org.apache.atlas.AtlasBaseClient.callAPI(AtlasBaseClient.java:427)
> at
> org.apache.atlas.AtlasClientV2.deleteAtlasTypeDefs(AtlasClientV2.java:258)
> at
> org.apache.atlas.examples.DeleteTypesFromJsonFileUtil.runTypeDelete(DeleteTypesFromJsonFileUtil.java:73)
> at
> org.apache.atlas.examples.DeleteTypesFromJsonFileUtil.main(DeleteTypesFromJsonFileUtil.java:58)
> Caused by: java.net.ProtocolException: HTTP method DELETE doesn't support
> output
> at
> sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1083)
> at
> com.sun.jersey.client.urlconnection.URLConnectionClientHandler$1$1.getOutputStream(URLConnectionClientHandler.java:238)
> at
> com.sun.jersey.api.client.CommittingOutputStream.commitStream(CommittingOutputStream.java:117)
> at
> com.sun.jersey.api.client.CommittingOutputStream.write(CommittingOutputStream.java:89)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at java.io.BufferedWriter.flush(BufferedWriter.java:254)
> at
> com.sun.jersey.core.util.ReaderWriter.writeToAsString(ReaderWriter.java:191)
> at
> com.sun.jersey.core.provider.AbstractMessageReaderWriterProvider.writeToAsString(AbstractMessageReaderWriterProvider.java:128)
> at
> com.sun.jersey.core.impl.provider.entity.StringProvider.writeTo(StringProvider.java:88)
> at
> com.sun.jersey.core.impl.provider.entity.StringProvider.writeTo(StringProvider.java:58)
> at
> com.sun.jersey.api.client.RequestWriter.writeRequestEntity(RequestWriter.java:300)
> at
> com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:217)
> at
> com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:153)
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ATLAS-2012) Docker - image & hub - for Atlas
[ https://issues.apache.org/jira/browse/ATLAS-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding updated ATLAS-2012: Attachment: atlas_docker.patch I think hbase_docker (HBASE-11885) is a good example. Attached is a modified version for Atlas development. It contains a Docker file that easily builds and run Atlas from source. You can easily startup/shutdown Atlas instances. You can run multiple Atlas instances on your laptop. > Docker - image & hub - for Atlas > > > Key: ATLAS-2012 > URL: https://issues.apache.org/jira/browse/ATLAS-2012 > Project: Atlas > Issue Type: New Feature >Reporter: Nigel Jones >Assignee: Péter Gergő Barna > Attachments: atlas_docker.patch > > > Docker is increasingly become a standard way of easily running components in > a flexible manner, whether for development, production, or test > I feel there are a few things we can do with docker that will aid Atlas's > appeal > 1. We could provide a simple example of how to create a docker image from the > Atlas build. This could be published on the wiki & it would make it easier > for developers to use Atlas within a docker environment - mostly by > addressing how to configure & start up > 2. We could automatically generate a docker image as part of the build > process. This builds on #1 by automating the creation of the image & making > it "just part of the build" > 3. We could publish the docker image from #2, for releases, to dockerhub, > making it near trivial for any developer to easily pull down and experiment > with Atlas. Full source of course would be provided/documented so that a user > could customize as needed for their environment plus of course improve what > is provided with the core project > 4. We could work with other teams especially ranger, to allow similar efforts > in other teams to easily work together & be orchestrated -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ATLAS-1953) Introduce the ability for icons to be associated with EntityDefs and RelaitonshipDefs
[ https://issues.apache.org/jira/browse/ATLAS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding reassigned ATLAS-1953: --- Assignee: Richard Ding (was: David Radley) > Introduce the ability for icons to be associated with EntityDefs and > RelaitonshipDefs > - > > Key: ATLAS-1953 > URL: https://issues.apache.org/jira/browse/ATLAS-1953 > Project: Atlas > Issue Type: Improvement >Reporter: David Radley >Assignee: Richard Ding > > Introduce the ability for icons to be defined in EntityDefs and > RelaitonshipDefs - these icons would be picked up by instances. This > facilitates visualization of entities and the like. The icon would have type > string and its value would be a url or a path relative to the webserver base > url. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ATLAS-1955) Validation for Attributes
[ https://issues.apache.org/jira/browse/ATLAS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding reassigned ATLAS-1955: --- Assignee: Richard Ding > Validation for Attributes > - > > Key: ATLAS-1955 > URL: https://issues.apache.org/jira/browse/ATLAS-1955 > Project: Atlas > Issue Type: New Feature > Components: atlas-core >Affects Versions: 0.9-incubating >Reporter: Israel Varea >Assignee: Richard Ding > Fix For: 0.9-incubating > > > It would be very nice that Atlas model could contain a way to represent > attribute validation. > A simple example is that we would like to model a Person, with attributes > Name, Email and Country. Now we would like to specify that Email has to > follow a specific regular expression, so it would be nice if we could set > Email -> hasValidation -> EmailRegex, with EmailRegex having: > Name: Email Regular Expresion > Expression: /[0-9a-z]+@[0-9a-z]+.[0-9a-z]+/ > For more complex types of validation, e.g. checking card number validity, it > could be added some external validator function/service. > Name: Credit Card Number Validator > Validator: org.apache.atlas.validators.creditcard or > https://host:port/creditCardValidator > For validations from a reference table, for example a country name, it could > be: > Name: Country Name Ref Validator > Reference Column: > where would be an instance of type Hive_Column or > HBase_Column. > Since this is a kind of Standarization, it could be placed in [Area > 5|https://cwiki.apache.org/confluence/display/ATLAS/Area+5+-+Standards]. > A similar approach is followed in software > [Kylo|https://github.com/Teradata/kylo/tree/master/integrations/spark/spark-validate-cleanse] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ATLAS-2003) Add Javadoc format to class summaries
[ https://issues.apache.org/jira/browse/ATLAS-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding updated ATLAS-2003: Attachment: before javadoc formating.png after javadoc formating.png Thanks [~davidrad] for reviewing the patch. Attached are two screenshots that show Javadoc in browsers before and after formatting. > Add Javadoc format to class summaries > - > > Key: ATLAS-2003 > URL: https://issues.apache.org/jira/browse/ATLAS-2003 > Project: Atlas > Issue Type: Improvement >Affects Versions: 0.8-incubating >Reporter: Richard Ding >Assignee: Richard Ding >Priority: Minor > Fix For: 0.9-incubating > > Attachments: after javadoc formating.png, ATLAS-2003.patch, before > javadoc formating.png > > > Java class summary needs to be formatted with HTML tags so that the generated > Javadoc can be properly displayed in browsers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ATLAS-2012) Docker - image & hub - for Atlas
[ https://issues.apache.org/jira/browse/ATLAS-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding updated ATLAS-2012: Attachment: atlas_docker_2.patch I tested the _Dockerfile_ on Mac and the Docker image was built successfully. The attached patch just removes the references to hbase in the comments and also the Windows newlines. I think it is ready for the review board. > Docker - image & hub - for Atlas > > > Key: ATLAS-2012 > URL: https://issues.apache.org/jira/browse/ATLAS-2012 > Project: Atlas > Issue Type: New Feature >Reporter: Nigel Jones >Assignee: Péter Gergő Barna > Attachments: atlas_docker1.patch, atlas_docker_2.patch, > atlas_docker.patch > > > Docker is increasingly become a standard way of easily running components in > a flexible manner, whether for development, production, or test > I feel there are a few things we can do with docker that will aid Atlas's > appeal > 1. We could provide a simple example of how to create a docker image from the > Atlas build. This could be published on the wiki & it would make it easier > for developers to use Atlas within a docker environment - mostly by > addressing how to configure & start up > 2. We could automatically generate a docker image as part of the build > process. This builds on #1 by automating the creation of the image & making > it "just part of the build" > 3. We could publish the docker image from #2, for releases, to dockerhub, > making it near trivial for any developer to easily pull down and experiment > with Atlas. Full source of course would be provided/documented so that a user > could customize as needed for their environment plus of course improve what > is provided with the core project > 4. We could work with other teams especially ranger, to allow similar efforts > in other teams to easily work together & be orchestrated -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ATLAS-1218) Atlas says it is started but does not accept REST requests
[
https://issues.apache.org/jira/browse/ATLAS-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Ding updated ATLAS-1218:
Attachment: ATLAS-1218_1.patch
The patch is simplified using Python socket module.
The patch was tested with commands:
{code}
$ bin/atlas-start.py
{code}
and
{code}
$ bin/atlas-start.py -port 31000
{code}
Also tested with TLS enabled.
> Atlas says it is started but does not accept REST requests
> --
>
> Key: ATLAS-1218
> URL: https://issues.apache.org/jira/browse/ATLAS-1218
> Project: Atlas
> Issue Type: Bug
>Affects Versions: 0.8-incubating
>Reporter: David Radley
>Assignee: Richard Ding
> Fix For: 0.9-incubating
>
> Attachments: ATLAS-1218_1.patch, ATLAS-1218.patch
>
>
> I start Atlas on the command line and it tells me is started - but REST
> requests are not accepted immediately. There appears to be asynchronous
> background processes that have not yet initialized. I feel that when Atlas
> says it is started it should be open for business and accept REST requests.
> a few seconds later REST requests are accepted.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ATLAS-1955) Validation for Attributes
[
https://issues.apache.org/jira/browse/ATLAS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129558#comment-16129558
]
Richard Ding commented on ATLAS-1955:
-
I have an offline discussion with [~davidrad] on how to add attribute
validations to the type system. It seems that option 2 is more clean by
separating validation rules from the attributes they validate. But it does add
another top level type to the system. Please let me know what you think.
*Option 1: Embed the validation rules inside attribute definition*
Add subclass AtlasValidationDef to AtlasStructDef class and AtlasValidationDef
will be an element of AtlasAttributeDef. For example, an email attribute can
contain a validation definition:
{code}
{
"name": "email",
"typeName": "string",
"cardinality": "SINGLE",
"validations": [
{
"type": "regex",
"validator": "[0-9a-z]@[0-9a-z].[0-9a-z]+"
}
],
"isIndexable": false,
"isOptional": true,
"isUnique": false
}
{code}
Notes:
# The validationDefs will be serialized / deserialized as part of attributeDef
Json string
# The validationDefs associated with attributeDefs will be retrieved and
invoked when validateValue or ValidateValueForUpdate (of AtlasStructType
class) is called.
# Initially, we’ll support three validation types: regex, lookup and class
#* regex: the validator value is a regex string
#* lookup: the validator value is the name of an existing AtlasEnumDef
#* class: the validator value is the name of a validator class (e.g.
org.apache.atlas.model.validation.CreditCardValidator). Validator classes all
implement AttributeValidator interface. These classes can be builtin (part of
Atlas), or dynamically loaded via Java provider framework.
*Option 2: Validation rules as top level type definition*
Here we define _AtlasAttributeValidationType_ (and
_AtlasAttributeValidationDef_) as top level Atlas type, similar to
_AtlasEnumType_ (and _AtlasEnumDef_), and add a optional validation field to
_AtlasAttributeDef_. For example, we first define
_AtlasAttributeValidationDefs_:
{code}
"validationDefs": [
{
"name": "email_validation",
"typeVersion": "1.0",
"type": "regex",
"validator": "[0-9a-z]@[0-9a-z].[0-9a-z]+"
},
{
"name": "country_code_validation",
"typeVersion": "1.0",
"type": "lookup",
"validator": "country_code_enum_type"
},
{
"name": "credit_card_validation",
"typeVersion": "1.0",
"type": "class",
"validator": "org.apache.atlas.model.validataion.CreditCardValidator"
}
]
{code}
Then we define the validation field in email attributeDef:
{code}
{
"name": "email",
"typeName": "string",
"cardinality": "SINGLE",
"validation": "email_validation",
"isIndexable": false,
"isOptional": true,
"isUnique": false
}
{code}
Notes:
# As a top level Atlas type, an AtlasAttibuteValidationType instance will be
stored as a vertex in the backing graph db.
# If validation field exists in an AtlasAttributeDef object, the attribute
value will be validated based on validationDef in method validateValue or
ValidateValueForUpdate (of AtlasStructType class)
# Initially, we’ll support three validation types: regex, lookup and class
> Validation for Attributes
> -
>
> Key: ATLAS-1955
> URL: https://issues.apache.org/jira/browse/ATLAS-1955
> Project: Atlas
> Issue Type: New Feature
> Components: atlas-core
>Affects Versions: 0.9-incubating
>Reporter: Israel Varea
>Assignee: Richard Ding
> Fix For: 0.9-incubating
>
>
> It would be very nice that Atlas model could contain a way to represent
> attribute validation.
> A simple example is that we would like to model a Person, with attributes
> Name, Email and Country. Now we would like to specify that Email has to
> follow a specific regular expression, so it would be nice if we could set
> Email -> hasValidation -> EmailRegex, with EmailRegex having:
> Name: Email Regular Expresion
> Expression: /[0-9a-z]+@[0-9a-z]+.[0-9a-z]+/
> For more complex types of validation, e.g. checking card number validity, it
> could be added some external validator function/service.
> Name: Credit Card Number Validator
> Validator: org.apache.atlas.validators.creditcard or
> https://host:port/creditCardValidator
> For validations from a reference table, for example a country name, it could
> be:
> Name: Country Name Ref Validator
> Reference Column:
> where would be an instance of type Hive_Column or
> HBase_Column.
> Since this is a kind of Standariz
[jira] [Updated] (ATLAS-1218) Atlas says it is started but does not accept REST requests
[ https://issues.apache.org/jira/browse/ATLAS-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding updated ATLAS-1218: Attachment: ATLAS-1218_2.patch > Atlas says it is started but does not accept REST requests > -- > > Key: ATLAS-1218 > URL: https://issues.apache.org/jira/browse/ATLAS-1218 > Project: Atlas > Issue Type: Bug >Affects Versions: 0.8-incubating >Reporter: David Radley >Assignee: Richard Ding > Fix For: 0.9-incubating > > Attachments: ATLAS-1218_1.patch, ATLAS-1218_2.patch, ATLAS-1218.patch > > > I start Atlas on the command line and it tells me is started - but REST > requests are not accepted immediately. There appears to be asynchronous > background processes that have not yet initialized. I feel that when Atlas > says it is started it should be open for business and accept REST requests. > a few seconds later REST requests are accepted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ATLAS-2060) Fix logger class name typos
Richard Ding created ATLAS-2060: --- Summary: Fix logger class name typos Key: ATLAS-2060 URL: https://issues.apache.org/jira/browse/ATLAS-2060 Project: Atlas Issue Type: Bug Components: atlas-intg Affects Versions: 0.8-incubating Reporter: Richard Ding Assignee: Richard Ding Priority: Trivial Fix For: 0.9-incubating There are two classes in intg module that have incorrect logger class names. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ATLAS-2060) Fix logger class name typos
[ https://issues.apache.org/jira/browse/ATLAS-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding updated ATLAS-2060: Attachment: ATLAS-2060.patch > Fix logger class name typos > --- > > Key: ATLAS-2060 > URL: https://issues.apache.org/jira/browse/ATLAS-2060 > Project: Atlas > Issue Type: Bug > Components: atlas-intg >Affects Versions: 0.8-incubating >Reporter: Richard Ding >Assignee: Richard Ding >Priority: Trivial > Fix For: 0.9-incubating > > Attachments: ATLAS-2060.patch > > > There are two classes in intg module that have incorrect logger class names. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ATLAS-2076) Add RELATIONSHIP type to search filters
Richard Ding created ATLAS-2076:
---
Summary: Add RELATIONSHIP type to search filters
Key: ATLAS-2076
URL: https://issues.apache.org/jira/browse/ATLAS-2076
Project: Atlas
Issue Type: Bug
Components: atlas-core
Affects Versions: 0.8-incubating
Reporter: Richard Ding
Assignee: Richard Ding
Priority: Minor
Fix For: 0.9-incubating
The command
{code}
curl -X GET -u admin:admin
http://localhost:21000/api/atlas/v2/types/typedefs/headers?type=relationship
{code}
returns empty result.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ATLAS-2076) Add RELATIONSHIP type to search filters
[
https://issues.apache.org/jira/browse/ATLAS-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Ding updated ATLAS-2076:
Attachment: ATLAS-2076.patch
> Add RELATIONSHIP type to search filters
> ---
>
> Key: ATLAS-2076
> URL: https://issues.apache.org/jira/browse/ATLAS-2076
> Project: Atlas
> Issue Type: Bug
> Components: atlas-core
>Affects Versions: 0.8-incubating
>Reporter: Richard Ding
>Assignee: Richard Ding
>Priority: Minor
> Fix For: 0.9-incubating
>
> Attachments: ATLAS-2076.patch
>
>
> The command
> {code}
> curl -X GET -u admin:admin
> http://localhost:21000/api/atlas/v2/types/typedefs/headers?type=relationship
> {code}
> returns empty result.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ATLAS-2076) Add RELATIONSHIP type to search filters
[
https://issues.apache.org/jira/browse/ATLAS-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Ding updated ATLAS-2076:
Attachment: ATLAS-2076_1.patch
The new patch added support for command:
{code}
curl -X GET -u admin:admin
http://localhost:21000/api/atlas/v2/types/typedef/name/dataset_process_inputs
{code}
> Add RELATIONSHIP type to search filters
> ---
>
> Key: ATLAS-2076
> URL: https://issues.apache.org/jira/browse/ATLAS-2076
> Project: Atlas
> Issue Type: Bug
> Components: atlas-core
>Affects Versions: 0.8-incubating
>Reporter: Richard Ding
>Assignee: Richard Ding
>Priority: Minor
> Fix For: 0.9-incubating
>
> Attachments: ATLAS-2076_1.patch, ATLAS-2076.patch
>
>
> The command
> {code}
> curl -X GET -u admin:admin
> http://localhost:21000/api/atlas/v2/types/typedefs/headers?type=relationship
> {code}
> returns empty result.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ATLAS-1955) Validation for Attributes
[
https://issues.apache.org/jira/browse/ATLAS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16136014#comment-16136014
]
Richard Ding commented on ATLAS-1955:
-
Thanks [~davidrad] and [~ivarea] for your comments and suggestions.
It seems that what we want here is a new custom attribute type defined as a
top-level type in Atlas type system. For example, we can have email and credit
card attribute types:
{code}
"attributeTypeDefs": [
{
"name": "email",
"typeVersion": "1.0",
"baseType": "string"
,
"validationType": "regex",
"validator": "[0-9a-z]@[0-9a-z].[0-9a-z]+"
},
{
"name": "credit_card",
"typeVersion": "1.0",
"baseType": "string",
"validationType": "class",
"validator": "org.apache.atlas.model.validataion.CreditCardValidator"
}
]
{code}
And these custom attribute types then can be used in entity attribute
definitions:
{code}
"entityDefs": [
{
"name":"Person",
"superTypes": [
"Referenceable"
],
"typeVersion":"1.0",
"attributeDefs":[
{
"name":"emailAddresses",
"typeName":"email",
"cardinality":"SET",
"isIndexable":true,
"isOptional":false,
"isUnique":false
},
{
"name":"creditCardNumbers",
"typeName":"credit_card",
"cardinality":"SET",
"isIndexable":true,
"isOptional":true,
"isUnique":false
},
……
}
]
{code}
Here _attributeTypeDefs_ is used to avoid confusion from _attributeDefs_
defined inside _entityDefs_.
> Validation for Attributes
> -
>
> Key: ATLAS-1955
> URL: https://issues.apache.org/jira/browse/ATLAS-1955
> Project: Atlas
> Issue Type: New Feature
> Components: atlas-core
>Affects Versions: 0.9-incubating
>Reporter: Israel Varea
>Assignee: Richard Ding
> Fix For: 0.9-incubating
>
>
> It would be very nice that Atlas model could contain a way to represent
> attribute validation.
> A simple example is that we would like to model a Person, with attributes
> Name, Email and Country. Now we would like to specify that Email has to
> follow a specific regular expression, so it would be nice if we could set
> Email -> hasValidation -> EmailRegex, with EmailRegex having:
> Name: Email Regular Expresion
> Expression: /[0-9a-z]+@[0-9a-z]+.[0-9a-z]+/
> For more complex types of validation, e.g. checking card number validity, it
> could be added some external validator function/service.
> Name: Credit Card Number Validator
> Validator: org.apache.atlas.validators.creditcard or
> https://host:port/creditCardValidator
> For validations from a reference table, for example a country name, it could
> be:
> Name: Country Name Ref Validator
> Reference Column:
> where would be an instance of type Hive_Column or
> HBase_Column.
> Since this is a kind of Standarization, it could be placed in [Area
> 5|https://cwiki.apache.org/confluence/display/ATLAS/Area+5+-+Standards].
> A similar approach is followed in software
> [Kylo|https://github.com/Teradata/kylo/tree/master/integrations/spark/spark-validate-cleanse]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ATLAS-1955) Validation for Attributes
[ https://issues.apache.org/jira/browse/ATLAS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16137157#comment-16137157 ] Richard Ding commented on ATLAS-1955: - [~davidrad] and [~mandy_chessell] suggested using _PrimitiveDefs_ instead of _attributeTypeDefs_. I think it is a better name for custom data types. > Validation for Attributes > - > > Key: ATLAS-1955 > URL: https://issues.apache.org/jira/browse/ATLAS-1955 > Project: Atlas > Issue Type: New Feature > Components: atlas-core >Affects Versions: 0.9-incubating >Reporter: Israel Varea >Assignee: Richard Ding > Fix For: 0.9-incubating > > > It would be very nice that Atlas model could contain a way to represent > attribute validation. > A simple example is that we would like to model a Person, with attributes > Name, Email and Country. Now we would like to specify that Email has to > follow a specific regular expression, so it would be nice if we could set > Email -> hasValidation -> EmailRegex, with EmailRegex having: > Name: Email Regular Expresion > Expression: /[0-9a-z]+@[0-9a-z]+.[0-9a-z]+/ > For more complex types of validation, e.g. checking card number validity, it > could be added some external validator function/service. > Name: Credit Card Number Validator > Validator: org.apache.atlas.validators.creditcard or > https://host:port/creditCardValidator > For validations from a reference table, for example a country name, it could > be: > Name: Country Name Ref Validator > Reference Column: > where would be an instance of type Hive_Column or > HBase_Column. > Since this is a kind of Standarization, it could be placed in [Area > 5|https://cwiki.apache.org/confluence/display/ATLAS/Area+5+-+Standards]. > A similar approach is followed in software > [Kylo|https://github.com/Teradata/kylo/tree/master/integrations/spark/spark-validate-cleanse] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ATLAS-2083) Refactor AtlasDefStore classes to reduce code duplication
Richard Ding created ATLAS-2083: --- Summary: Refactor AtlasDefStore classes to reduce code duplication Key: ATLAS-2083 URL: https://issues.apache.org/jira/browse/ATLAS-2083 Project: Atlas Issue Type: Improvement Components: atlas-core Affects Versions: 0.8-incubating Reporter: Richard Ding Assignee: Richard Ding Fix For: 0.9-incubating Currently each top-level TypeDef defines its own DefStore interface. These interfaces have the same methods. I suggest that we use generic interface to reduce the code duplication. We can also tighten the type restriction on these interfaces. Replacing Object reference with AtlasVertex reference. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ATLAS-2083) Refactor AtlasDefStore classes to reduce code duplication
[ https://issues.apache.org/jira/browse/ATLAS-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding updated ATLAS-2083: Attachment: ATLAS-2083.patch > Refactor AtlasDefStore classes to reduce code duplication > --- > > Key: ATLAS-2083 > URL: https://issues.apache.org/jira/browse/ATLAS-2083 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 0.8-incubating >Reporter: Richard Ding >Assignee: Richard Ding > Fix For: 0.9-incubating > > Attachments: ATLAS-2083.patch > > > Currently each top-level TypeDef defines its own DefStore interface. These > interfaces have the same methods. I suggest that we use generic interface to > reduce the code duplication. > We can also tighten the type restriction on these interfaces. Replacing > Object reference with AtlasVertex reference. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ATLAS-2083) Refactor AtlasDefStore classes to reduce code duplication
[ https://issues.apache.org/jira/browse/ATLAS-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Ding updated ATLAS-2083: Attachment: ATLAS-2083_1.patch Rebased the patch on the latest master branch. > Refactor AtlasDefStore classes to reduce code duplication > --- > > Key: ATLAS-2083 > URL: https://issues.apache.org/jira/browse/ATLAS-2083 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 0.8-incubating >Reporter: Richard Ding >Assignee: Richard Ding > Fix For: 0.9-incubating > > Attachments: ATLAS-2083_1.patch, ATLAS-2083.patch > > > Currently each top-level TypeDef defines its own DefStore interface. These > interfaces have the same methods. I suggest that we use generic interface to > reduce the code duplication. > We can also tighten the type restriction on these interfaces. Replacing > Object reference with AtlasVertex reference. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ATLAS-2087) Atlas server always binds to address 0.0.0.0.
Richard Ding created ATLAS-2087:
---
Summary: Atlas server always binds to address 0.0.0.0.
Key: ATLAS-2087
URL: https://issues.apache.org/jira/browse/ATLAS-2087
Project: Atlas
Issue Type: Bug
Components: atlas-core
Affects Versions: 0.8-incubating
Reporter: Richard Ding
Assignee: Richard Ding
Fix For: 0.9-incubating
Atlas server always bind to address "0.0.0.0":
{code}
connector.setHost("0.0.0.0");
{code}
But in many cases, user want to only run Atlas on a specified IP address (e.g.
private network).
The existing property "_atlas.server.bind.address_" should be used:
{code}
final String addr = conf.get("atlas.server.bind.address", "0.0.0.0");
connector.setHost(addr);
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ATLAS-2087) Allow Atlas server to bind on a specific address
[
https://issues.apache.org/jira/browse/ATLAS-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Ding updated ATLAS-2087:
Issue Type: Improvement (was: Bug)
> Allow Atlas server to bind on a specific address
>
>
> Key: ATLAS-2087
> URL: https://issues.apache.org/jira/browse/ATLAS-2087
> Project: Atlas
> Issue Type: Improvement
> Components: atlas-core
>Affects Versions: 0.8-incubating
>Reporter: Richard Ding
>Assignee: Richard Ding
> Fix For: 0.9-incubating
>
>
> Atlas server always bind to address "0.0.0.0":
> {code}
> connector.setHost("0.0.0.0");
> {code}
> But in many cases, user want to only run Atlas on a specified IP address
> (e.g. private network).
> The existing property "_atlas.server.bind.address_" should be used:
> {code}
> final String addr = conf.get("atlas.server.bind.address", "0.0.0.0");
> connector.setHost(addr);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ATLAS-2087) Allow Atlas server to bind on a specific address
[
https://issues.apache.org/jira/browse/ATLAS-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Ding updated ATLAS-2087:
Summary: Allow Atlas server to bind on a specific address (was: Atlas
server always binds to address 0.0.0.0.)
> Allow Atlas server to bind on a specific address
>
>
> Key: ATLAS-2087
> URL: https://issues.apache.org/jira/browse/ATLAS-2087
> Project: Atlas
> Issue Type: Bug
> Components: atlas-core
>Affects Versions: 0.8-incubating
>Reporter: Richard Ding
>Assignee: Richard Ding
> Fix For: 0.9-incubating
>
>
> Atlas server always bind to address "0.0.0.0":
> {code}
> connector.setHost("0.0.0.0");
> {code}
> But in many cases, user want to only run Atlas on a specified IP address
> (e.g. private network).
> The existing property "_atlas.server.bind.address_" should be used:
> {code}
> final String addr = conf.get("atlas.server.bind.address", "0.0.0.0");
> connector.setHost(addr);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ATLAS-2083) Refactor AtlasDefStore classes to reduce code duplication
[ https://issues.apache.org/jira/browse/ATLAS-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16144340#comment-16144340 ] Richard Ding commented on ATLAS-2083: - Thank you for the reviews [~madhan.neethiraj]. > Refactor AtlasDefStore classes to reduce code duplication > --- > > Key: ATLAS-2083 > URL: https://issues.apache.org/jira/browse/ATLAS-2083 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 0.8-incubating >Reporter: Richard Ding >Assignee: Richard Ding > Fix For: 0.9-incubating > > Attachments: ATLAS-2083_1.patch, ATLAS-2083.patch > > > Currently each top-level TypeDef defines its own DefStore interface. These > interfaces have the same methods. I suggest that we use generic interface to > reduce the code duplication. > We can also tighten the type restriction on these interfaces. Replacing > Object reference with AtlasVertex reference. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ATLAS-2087) Allow Atlas server to bind on a specific address
[
https://issues.apache.org/jira/browse/ATLAS-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Ding updated ATLAS-2087:
Attachment: ATLAS-2087.patch
> Allow Atlas server to bind on a specific address
>
>
> Key: ATLAS-2087
> URL: https://issues.apache.org/jira/browse/ATLAS-2087
> Project: Atlas
> Issue Type: Improvement
> Components: atlas-core
>Affects Versions: 0.8-incubating
>Reporter: Richard Ding
>Assignee: Richard Ding
> Fix For: 0.9-incubating
>
> Attachments: ATLAS-2087.patch
>
>
> Atlas server always bind to address "0.0.0.0":
> {code}
> connector.setHost("0.0.0.0");
> {code}
> But in many cases, user want to only run Atlas on a specified IP address
> (e.g. private network).
> The existing property "_atlas.server.bind.address_" should be used:
> {code}
> final String addr = conf.get("atlas.server.bind.address", "0.0.0.0");
> connector.setHost(addr);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ATLAS-2087) Allow Atlas server to bind on a specific address
[
https://issues.apache.org/jira/browse/ATLAS-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Ding updated ATLAS-2087:
Attachment: ATLAS-2087.addendum.patch
As pointed out by [~madhan.neethiraj] in his review comments, localhost:21000
is not the same endpoint as :21000 unless the server is bound to address
"0.0.0.0".
This addendum addresses this issue in the startup script. I've tested the
script with following property settings:
{code}
atlas.server.bind.address=
atlas.server.bind.address=0.0.0.0
atlas.server.bind.address=127.0.0.1
{code}
> Allow Atlas server to bind on a specific address
>
>
> Key: ATLAS-2087
> URL: https://issues.apache.org/jira/browse/ATLAS-2087
> Project: Atlas
> Issue Type: Improvement
> Components: atlas-core
>Affects Versions: 0.8-incubating
>Reporter: Richard Ding
>Assignee: Richard Ding
> Fix For: 0.9-incubating
>
> Attachments: ATLAS-2087.2.patch, ATLAS-2087.addendum.patch,
> ATLAS-2087.patch
>
>
> Atlas server always bind to address "0.0.0.0":
> {code}
> connector.setHost("0.0.0.0");
> {code}
> But in many cases, user want to only run Atlas on a specified IP address
> (e.g. private network).
> The existing property "_atlas.server.bind.address_" should be used:
> {code}
> final String addr = conf.get("atlas.server.bind.address", "0.0.0.0");
> connector.setHost(addr);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ATLAS-2087) Allow Atlas server to bind on a specific address
[
https://issues.apache.org/jira/browse/ATLAS-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148038#comment-16148038
]
Richard Ding commented on ATLAS-2087:
-
[~sarath.ku...@gmail.com], let I look into UT failures.
> Allow Atlas server to bind on a specific address
>
>
> Key: ATLAS-2087
> URL: https://issues.apache.org/jira/browse/ATLAS-2087
> Project: Atlas
> Issue Type: Improvement
> Components: atlas-core
>Affects Versions: 0.8-incubating
>Reporter: Richard Ding
>Assignee: Richard Ding
> Fix For: 0.9-incubating
>
> Attachments: ATLAS-2087.2.patch, ATLAS-2087.addendum.patch,
> ATLAS-2087.patch
>
>
> Atlas server always bind to address "0.0.0.0":
> {code}
> connector.setHost("0.0.0.0");
> {code}
> But in many cases, user want to only run Atlas on a specified IP address
> (e.g. private network).
> The existing property "_atlas.server.bind.address_" should be used:
> {code}
> final String addr = conf.get("atlas.server.bind.address", "0.0.0.0");
> connector.setHost(addr);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (ATLAS-2087) Allow Atlas server to bind on a specific address
[
https://issues.apache.org/jira/browse/ATLAS-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148038#comment-16148038
]
Richard Ding edited comment on ATLAS-2087 at 8/30/17 9:30 PM:
--
[~sarath.ku...@gmail.com], let me look into UT failures.
was (Author: rding):
[~sarath.ku...@gmail.com], let I look into UT failures.
> Allow Atlas server to bind on a specific address
>
>
> Key: ATLAS-2087
> URL: https://issues.apache.org/jira/browse/ATLAS-2087
> Project: Atlas
> Issue Type: Improvement
> Components: atlas-core
>Affects Versions: 0.8-incubating
>Reporter: Richard Ding
>Assignee: Richard Ding
> Fix For: 0.9-incubating
>
> Attachments: ATLAS-2087.2.patch, ATLAS-2087.addendum.patch,
> ATLAS-2087.patch
>
>
> Atlas server always bind to address "0.0.0.0":
> {code}
> connector.setHost("0.0.0.0");
> {code}
> But in many cases, user want to only run Atlas on a specified IP address
> (e.g. private network).
> The existing property "_atlas.server.bind.address_" should be used:
> {code}
> final String addr = conf.get("atlas.server.bind.address", "0.0.0.0");
> connector.setHost(addr);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ATLAS-2087) Allow Atlas server to bind on a specific address
[
https://issues.apache.org/jira/browse/ATLAS-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Ding updated ATLAS-2087:
Attachment: ATLAS-2087_fixUT.addendum.patch
The problem seems to be that many unit tests are skipped when running command
{code}
mvn test
{code}
The following command runs all tests:
{code}
mvn clean install -DskipCheck -DskipITs
{code}
The new addendum fixes the UT failures.
Thanks [~sarath.ku...@gmail.com].
> Allow Atlas server to bind on a specific address
>
>
> Key: ATLAS-2087
> URL: https://issues.apache.org/jira/browse/ATLAS-2087
> Project: Atlas
> Issue Type: Improvement
> Components: atlas-core
>Affects Versions: 0.8-incubating
>Reporter: Richard Ding
>Assignee: Richard Ding
> Fix For: 0.9-incubating
>
> Attachments: ATLAS-2087.2.patch, ATLAS-2087.addendum.patch,
> ATLAS-2087_fixUT.addendum.patch, ATLAS-2087.patch
>
>
> Atlas server always bind to address "0.0.0.0":
> {code}
> connector.setHost("0.0.0.0");
> {code}
> But in many cases, user want to only run Atlas on a specified IP address
> (e.g. private network).
> The existing property "_atlas.server.bind.address_" should be used:
> {code}
> final String addr = conf.get("atlas.server.bind.address", "0.0.0.0");
> connector.setHost(addr);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
